HTML5: custom video player

[johnhudson]

Interesting article but

1. typographically, code points U2018 (‘), U2019 (’), U201C (“) and U201D (”) will cause browsers to freeze or display errors if they are used in code;

2. from the HTML Standard: ‘Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.’

Wouldn't it be better in a tutorial to offer examples that represent best practice?

[guy]

Haven't seen the article but evangelising the politically correct usage of HTML5 made me laugh. Reality check? What heresy, we have a religion on our hands.

[ChriThor]

Thanks John,

We'll need to use the special chars in InDesign to avoid that in future.

My assumption is that people would be typing this in or taking it from the source code, which should avoid unicode problems.

[johnhudson]

Haven't seen the article but evangelising the politically correct usage of HTML5 made me laugh. Reality check? What heresy, we have a religion on our hands.

Not politically correct; just best practice. Have a look at http://www.whatwg.org/specs/web-apps/current-work/ and tell me what is wrong with it.

[guy]

Haven't seen the article but evangelising the politically correct usage of HTML5 made me laugh. Reality check? What heresy, we have a religion on our hands.

Not politically correct; just best practice. Have a look at http://www.whatwg.org/specs/web-apps/current-work/ and tell me what is wrong with it.

"Best practice" - really? Best for whom?

The core problem is its mantra to move away from the original user-centric language and instead to take a rigid bottom-up view of the distinction between structure, content and style. That has never worked and never will. Web pages and the people who write them are top-down things. That would be okay as a rule book for a programming language, but not for a language to be used by us mere mortals.

Style is, supposedly, banished ruthlessly to CSS, with html reserved for semantics. In practice this has neither happened nor can happen.

HTML Tables layout is reserved for data, and for page layout it is a Sin. But what if I want a table-like page layout? Why, how kind, the CSS table model provides all the missing table components. Oops, except for things like the analogues of cellspacing, cellpadding, rowspan, colspan, which are now an utter nightmare to implement. But hey, these CSS constructs were actually introduced in order to present a tabular display where the programming language has no concept of such a thing. Oops again. Instead of old Devils like me styling page layouts using semantic tables, we now have HTML5 Angels coding semantic tables using a styling language - broken our mantra there all right.

Then there is the fact that most people rely on visual clues in a way that does not separate structure, content and style in a rigid way. Is a page layout a semantic thing or a styling thing? CSS has a concept of "normal flow": content is presented in the order it appears in the sequential flow of the source page. Is normal flow a semantic or stylistic concept. Well, if we break normal flow and present Section 2 above Section 1, I think you will agree that the presentation has broken the semantics of the content. Here, breaking normal flow has broken the semantics. But now consider a centrally-focused layout with boxouts all around. We may happily code the boxouts in any order because we must break normal flow in order to position each to best effect. This time, breaking normal flow does not break the semantics. This helps to illustrate how the relative positioning of objects is sometimes a matter of semantics and sometimes a matter of style. Page layout cannot be cleanly dumped in either camp, and separating the two into distinct languages makes an utter cabbage of the way many page designers go about their business.

Every DTP pro will tell you how important frames are. html5 hates frames, only the iframe is left, as a kind of apology for a media container. The html5 designer must resort to floating divs all over the place and managing how they jump around. More cabbage for the page designer.

Consider how the em and strong elements have wholly failed to replace the b and i elements and must now exist uneasily alongside. em and strong are semantic concepts, b and i are styling concepts.

Sorry, but HTML5 may be intended as a coder's paradise but the truth is, time and again the hard facts of life force it to break its own mantras. And even when it doesn't, there are plenty of real people out here with the strongest of practical motivations to do that for it.

Oh, yeah, and then there's accessibility. I once coded duplicate web pages using nested html tables and css to lay it out, then a blind friend with a reader visited them. The html page read flawlessly, the css read backwards because the reader assumed normal flow. When I told him the html was not only tables but nested he was astonished - his reader had treated them utterly transparently and he had no clue they were there. So don't start.

[Update] Here's another way to look at the fundamental problem. HTML1 tried to provide a semantic model for the styling of content, while HTML5 seeks to provide a styling model (CSS) for the semantics of the content. It's back to front. IMHO we should be enhancing the original model, including:

Reintroduce frames as a layout tool, so we really can limit Tables to tabular data.
Compatibility between frame transclusion and browser navigation.
Adding units like pt and em to html attribute values
Normalise attributes across elements by allowing elements more kinds of attribute, not less.

"Oh no", you cry, "you have borked my nice semantic DOM". Have I? Then take a leaf out of the MathML book. Over there they have the problem that a given semantic object (such as a decimal division) may be represented by different characters (a comma, a period, a mid-dot) in different mathematical representations, aka styling schemes, while a given symbol (such as a period) can represent different semantic objects (times, decimal division) in different mathematical representations. The have had to resort to dividing the supposedly purely semantic idea of elements into presentation, content and semantic elements - the semantic element being a recursive idea of a semantic construct whose job it is to define the content as a semantic construct, whoop-de-doop. Being an approved HTML5 extension for use in web pages, your nice DOM must of course be compatible with all that MathML semantic spaghetti. So no, I haven't borked your DOM at all, it's already way ahead of you. You just need to recognise the heresy that some elements are semantic in nature and some are not, just like mathematicians already do.

One more for luck. We have seen there is a difference between presentation and semantic elements. The html div element is a purely semantic construct, designed to contain a set of semantically related constructs. But it is also intended to be used to put a presentational box around a set of visually related constructs. In other words, the div is a dog's breakfast of an element. To get a clean system, it is necessary to split it into two distinct types of element - the one purely semantic (no styling permitted) and the other purely visual. In my scheme above, I suggest that the frame be resurrected for the presentational aspect.

Have I told you enough yet about what is wrong with HTML5?

[johnhudson]

Obviously we live in different worlds!

Strange that the coders at Apple, Mozilla and Opera don't agree with you and, as a DTP professional, I find frames a nightmare; they interfere with rather than help in the layout of pages.

If the old approaches to HTML and XHTML were so good, why were there so few well designed web pages?

[johnhudson]

To expand on the different worlds point:

Web pages and the people who write them are top-down things.

Not quite sure what you intended by this but it certainly encapsulates what is wrong with most websites; they fail to pay attention to the horizontal relationships between content on different pages and also the relationships which the user sees between content on different pages.

Is a page layout a semantic thing or a styling thing?

Semantic. When I first got involved in page layout in the 1960s, there were no frames. Page design was based on position, proximity and relationships and the aim was to ensure that, as the reader scanned the page, they picked up all the important messages in it. Style was entirely subservient to semantics. So for me using HTML for semantics and CSS for style is entirely natural and would be for anyone brought up to design pages before frames were invented.

When I first started using computers, there were no frames. They were introduced to solve a page generation problem and, like WYSIWYG, they became a marketing device.

Frames hardly ever have a semantic or a styling function (unless of course you are committed to using them in this way). When I use a frame based program, I have to use frames to create the semantics of the page; only very rarely do I use them as a semantic in their own right.

But what if I want a table-like page layout?

That is exactly the type of layout we would have been condemned for creating; apart from horizontal lines below a banner/header and above a footer, any horizontal or vertical line across the whole of the body of the text breaks up the page and the smooth flow from one part of the page to another.

... most people rely on visual clues in a way that does not separate structure, content and style in a rigid way.

That is the point of the way I was taught to design pages.

But now consider a centrally-focused layout with boxouts all around.

This is the exception that proves the rule; there are occasions when I have used a centrally focused layout to demonstrate something and then I have used an image. However, there are very few situations in which starting a reader's eye in the centre of a page is a good idea; what is the scanning pattern: centre - perimeter - centre - perimeter - etc.? Or centre - perimeter and then clockwise or anti-clockwise round the centre?

There is no reason why HTML5 should not have a semantic object capable of doing what you want. I just hope that people would only use it in the small number of situations for which it was appropriate.

This helps to illustrate how the relative positioning of objects is sometimes a matter of semantics and sometimes a matter of style.

Not in my book; relative position is always a matter of semantics.

HTML5 seeks to provide a styling model (CSS) for the semantics of the content.

I think that slightly misses the point; the semantics are in the page design; the styling of the content should support the semantics.

Adding units like pt and em to html attribute values Normalise attributes across elements by allowing elements more kinds of attribute, not less.

Not sure what you mean by this; there are lots of attributes of many different kinds that can be applied to elements.

Have I told you enough yet about what is wrong with HTML5?

No; it seems to me that your arguments simply show that you are living in a different world from me.

[guy]

To expand on the different worlds point:

Web pages and the people who write them are top-down things.

Not quite sure what you intended by this but it certainly encapsulates what is wrong with most websites; they fail to pay attention to the horizontal relationships between content on different pages and also the relationships which the user sees between content on different pages.

I mean it abstractly, in a conceptual approach kind of way, not the physical scanning, which differs among national groups.

Is a page layout a semantic thing or a styling thing?

Semantic. ... Frames hardly ever have a semantic or a styling function

Yet frames are entirely a page layout thing, so I cannot make sense of what you say.

But what if I want a table-like page layout?

That is exactly the type of layout we would have been condemned for creating; apart from horizontal lines below a banner/header and above a footer, any horizontal or vertical line across the whole of the body of the text breaks up the page and the smooth flow from one part of the page to another.

I meant "table-like" in the sense of block-based. Rowspan and colspan are the html way of avoiding those cross-body breaks, the css way uses superposition of oversized elements to paper them over. This kind of block-based layout is very common in organisational "house styles" such as the UK Government - my meat-and-drink for the last 20 years - where it often has to work in printed A4 page format, too. You might think, "well, stick to PDF", but don't forget that HTML5 is the w3c Master Plan to replace such unfortunately practical inconveniences, it's not just a way to get journalistic content online.

... most people rely on visual clues in a way that does not separate structure, content and style in a rigid way.

That is the point of the way I was taught to design pages.

But now consider a centrally-focused layout with boxouts all around.

This is the exception that proves the rule; there are occasions when I have used a centrally focused layout to demonstrate something and then I have used an image. However, there are very few situations in which starting a reader's eye in the centre of a page is a good idea; what is the scanning pattern: centre - perimeter - centre - perimeter - etc.? Or centre - perimeter and then clockwise or anti-clockwise round the centre?

There is no reason why HTML5 should not have a semantic object capable of doing what you want. I just hope that people would only use it in the small number of situations for which it was appropriate.

It should certainly not be an exception. Different people respond to different visual cues. Some will home in on the prettiest graphic, others on the boldest text, others the top-right cornet (or whatever their national convention). A good layout caters for all of these. A typical scanning paradigm (hardly a "pattern") for such a page is to start in the middle and then move progressively outwards in whatever direction meets your interest, possibly in a zigzag path. At each node, when the reader is ready to move on, the eye scans the surrounding area in whatever mode is most appropriate to the reader's anticipation: more detail, a peer node, back to the core? This can be very effective in, say, a stakeholder analysis for a large and complex project.

I agree entirely that HTML should have such constructs. But it doesn't, so at lest we agree about one imperfection!

This helps to illustrate how the relative positioning of objects is sometimes a matter of semantics and sometimes a matter of style.

Not in my book; relative position is always a matter of semantics.

Then why, do you think, is the coding of relative positioning confined to CSS, the styling language?

HTML5 seeks to provide a styling model (CSS) for the semantics of the content.

I think that slightly misses the point; the semantics are in the page design; the styling of the content should support the semantics.

My point is that this is not always true. If it were, then you could design your page without using CSS to position anything. And certainly, not all the semantics are to be found in the design.

Adding units like pt and em to html attribute values Normalise attributes across elements by allowing elements more kinds of attribute, not less.

Not sure what you mean by this; there are lots of attributes of many different kinds that can be applied to elements.

Not enough! Ever tried defining the cellpadding attribute in em? Ever tried getting valign to work inside a single table cell? Or, are you mistaking css attributes for the html attributes I was talking about?

Have I told you enough yet about what is wrong with HTML5?

No; it seems to me that your arguments simply show that you are living in a different world from me.

We are certainly living in different worlds. But your remark implies that my professional world is not as valid as yours. I find that a somewhat untenable limitation in a community designed for openness, or for a coding scheme which brags that it is flexible enough to build an entire GUI.

[johnhudson]

We are certainly living in different worlds. But your remark implies that my professional world is not as valid as yours. I find that a somewhat untenable limitation in a community designed for openness, or for a coding scheme which brags that it is flexible enough to build an entire GUI.

Sorry, no - I meant that I had been brought up in a different professional tradition. You seemed to be implying in your earlier response that your professional world was the only one. I was simply trying to explain that there is a long-standing alternative - one which made me rather more sympathetic to the changes brought in by HTML5.

I will reflect in detail on your comments because I learned long ago that it is useful to treat differences of opinion as helpful.

[guy]

Sorry, no - I meant that I had been brought up in a different professional tradition. You seemed to be implying in your earlier response that your professional world was the only one. I was simply trying to explain that there is a long-standing alternative - one which made me rather more sympathetic to the changes brought in by HTML5.

I will reflect in detail on your comments because I learned long ago that it is useful to treat differences of opinion as helpful.

Thank you. Nor am I trying to make out that my viewpoint is the only truth, merely that the gospel according to the w3c is not so, either.