[whatwg] Updated index of all HTML elements
(Apologies to those who’ve seen this already on the W3C HTML list:) FYI/FWIW, the HTML index at http://meiert.com/en/indices/html-elements/ now includes spec links for all elements, as well as HTML 2.0 which makes it span all major versions of HTML. (A few more notes at https://plus.google.com/+JensOMeiert/posts/2w14E3V7bFc.) PS. Steve Faulkner has created http://rawgithub.com/w3c/elements-of-html/master/index.html on the basis of the other index. We’ll see what we come up with overall. -- Jens O. Meiert http://meiert.com/en/
[whatwg] HTML and spec fragmentation (WHATWG)
A bigger issue with CSS, HTML too seems to suffer from spec fragmentation. I’m explaining my perspective on the problem and options in the following place simply because of the unique setup of the different groups working on HTML and CSS: http://meiert.com/en/blog/20131205/spec-fragmentation/ I believe for HTML, we should establish authoritative overview pages on both the W3C and the WHATWG side (to mitigate the problem of people not finding and comprehending all relevant documents), and to also look into a refactoring as well as policy adjustments. (I’m raising this as an issue on the W3C side separately, honoring the different groups’ preferences.) -- Jens O. Meiert http://meiert.com/en/ ✍ New book! http://meiert.com/everyday-adventurer
Re: [whatwg] HTML differences from HTML4 document updated
I understand the amount of space it takes. I still don't understand what the problem is. Is it that people look at the scrollbar and think oh wow this document is too long, I'm not gonna bother reading it at all.? Or something else? That is one scenario which could have an effect on how many people actually read the document. It is a particular nuisance for print; it is also one on mobile. With neither being high per se, I suggest the cost of problem is higher than the cost of solution, and I thus hope this is worth addressing. I don’t have anything else to add :) -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] HTML differences from HTML4 document updated
Unrelated to the rest of the conversation, could we reconsider whether every version of this document needs to list *all* document-internal changes, in section 6? This document doesn't have versions (anymore). Is the length of that section a problem? Yes. It’s probably a lesser important part of the document but it appears to take up about half of the space (or blows the document up to double its size, respectively). -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] HTML differences from HTML4 document updated
http://html-differences.whatwg.org/ Thanks Simon! Unrelated to the rest of the conversation, could we reconsider whether every version of this document needs to list *all* document-internal changes, in section 6? I’d argue it suffices to list the changes to the last version of the document. This keeps the document length at bay while it’s still possible for people who are actually interested in all changes to go back and check for them. Cheers, Jens. -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] A plea to Hixie to adopt main
Should main be optional or required? I’d deem an optional main to be nonsense because it suggests documents are inherently without goal, or focus. I’d deem a required main to be nonsense because we already have an (implied) body element, and because element proliferation doesn’t work in anyone’s favor. That body essentially means main always seemed reasonable to me. There are plenty of options for authors to add styling hooks if they need any, including div role=main. -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] abbr inside of option
Just curious: What is the reasoning behind the option element not being able to contain abbr elements? What problem would this solve? I think this question came up a few times, also in the context of the “title” element; to try a very quick abstraction, it seems logical that the content model of every non-void HTML element (with the only exception of form elements?) should allow (most) phrasing content. Having asked the question too for “title” at some point the reasoning is that you could not express the meaning of these elements’ contents otherwise. Or, why should “h1abbrHTML/abbr/h1” be acceptable but “titleabbrHTML/abbr/title” not be permitted—in both cases, “HTML” is an abbreviation. (No need to explain the situation around the “title” element again, I just like the example.) -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] [html5] @formaction, @formenctype, @formmethod, @formnovalidate, @formtarget
It was that way before, but many pages were already using those attributes and expected the browser to not do anything with them. I understand that good judgment will have been applied. Hence out of mere curiosity, do you happen to have any data to share: how many documents (out of how many more) are we talking about, and in how many instances would problems have arisen (I understand reuse of the same attribute values not to cause any, as in “form action=fooinput action=foo/form”)? Thanks! Jens. -- Jens O. Meiert http://meiert.com/en/
[whatwg] [html5] @formaction, @formenctype, @formmethod, @formnovalidate, @formtarget
I realize that the @formaction, @formenctype, @formmethod, @formnovalidate, and @formtarget attributes on “input” and “button” elements are not quite new to HTML 5 anymore, however would someone mind sharing with me why we don’t just simply allow @action, @enctype, @method, @novalidate, and @target to serve the exact same purpose? Would any existing behavior of user agents stand in the way of this, or is there any other kind of incompatibility (examples appreciated)? Pending any oversight, allowing the same attribute names seems straight-forward, simple, and way easier to use. -- Jens O. Meiert http://meiert.com/en/
Re: [whatwg] Suggestion for CSS-RESET property in CSS3 ((tag: css3, html5, css-reset, idea))
(+www-st...@w3.org) I think, web developed should be done modular design approach. For example, A cool CSS button or may be JavaScripted button [on a different site] can have this code. Now if somebody else want to reuse the code he can use div id=some id css-reset style blah blah blah /style html blah blah blah /html script blah blah blah /script /div css-reset property will restrict or reset CSS or JavaScript processing inside that particular node div/. Why would you not want to tailor to your needs what you … reuse? Independent of the fact that the specs will not spare authors from doing some work on their own, both HTML and CSS should already offer ways to cope with said use case beyond introducing something like a @css-reset. For instance, HTML 5 is about to introduce @scoped on the “style” element [1]; style sheets can not only be edited (to remove what you don’t need) but CSS also offers some leeway via “inherit” [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped [2] http://www.w3.org/TR/CSS21/cascade.html#value-def-inherit -- Jens O. Meiert http://meiert.com/en/
