Re: [whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment
On 10/9/19 8:10 PM, Nick Burris wrote: Summary Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information. So, like, this sounds conceptually like a great feature to have for the Web. But this Edge: No signals Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194> Safari: No signals makes it seem like you really haven't put much effort into figuring out where the other browser vendors stand on the issue. Given this is an Intent to Ship, I interpret not having figured out where the other vendors stand even at the coarse level of “excited to have spec, plan to implement”, “supportive but not prioritizing; will accept patches”, or “opposed to the feature in its current state” as not really caring what they think. You have contacts into these organizations; I am sure you could solicit such answers where there aren't any if you thought it was necessary. Google engineers keep asserting that, no, we really care about standardization and moving the Web forward together with the other browser vendors. Look at the processes we made to help us do that! But Web standardization efforts have always tried to move forward on the basis of consensus. Meanwhile the attitude here seems to be ”There was a template for the positions of other browsers, a blank answer could be provided in the template, nobody reviewing it cares that there was a blank answer, so let's just ship the thing we (Google) want.” If this was a blank code review in your template, I imagine you would try harder to get the reviewer's answer, and give a good explanation of your attempts and their failure if indeed you could not solicit a response, before asking for lgtm. Yoav Weiss wrote: When it comes to venue, the current spec's processing seems to be mostly monkey-patching the HTML and URL specs, indicating that WHATWG is probably the right venue for this to graduate to. At the same time, landing features in WHATWG specs require multi-engine commitment, and looking at Mozilla's 2.5-months-old standards position issue doesn't really indicate implementer commitment, or anything at all. From a practical standpoint, it's clearer and easier for the spec to live as a standalone document rather than a WHATWG PR, while we're waiting for multi-engine commitment. But, that in no means preclude collaboration. The spec is in WICG, which was built specifically to enable multi-vendor collaboration when incubating new ideas. I'm sure everyone would be thrilled to have your feedback directly there, to make sure we get this right. I would like to point out a couple things: 1. WICG is explicitly billing itself an incubation venue, not a standardization venue. At the point you're planning to ship a feature, I think that qualifies as beyond incubation, yes? So continuing work there at this point would be inappropriate. 2. If the WHATWG rules for incorporating something are too stringent to allow standardization in a timely manner, maybe you should consider changing them? It's not like Google has no say in the WHATWG process. Perhaps something like “two implementation commitments *or* implemented in one browser with other browsers at least in favor of the feature and willing to implement it at some point in the future even if they haven't committed to apply their own resources yet” could be enough for inclusion. To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good work: if your process is inhibiting you from doing said work, you should fix said process. Allowing Google to do standardization work in an appropriate multi-vendor standards forum, and using that process to seek positive consensus on its proposals prior to deciding to ship, would be better than the circumvention of the standardization processes *and spirit* being demonstrated here, I would think. ~fantasai
[whatwg] [CSSWG][css-lists-3] Updated WD of CSS Lists Level 3
The CSS WG has published an updated Working Draft of the CSS Lists Module Level 3: https://www.w3.org/TR/css-lists-3/ This module contains CSS features related to list markers and counters: styling them, positioning them, and manipulating their value. This update contains a major clean-up of the “Automatic Numbering with Counters” section, including fixing various sync errors against CSS2.1. It should now be usable as a reference for implementation. [See also announcement on the previous update, which was a rewrite of the list-styling section: https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html ] Major areas of work left include: - Improving definitions for how list markers are positioned and how they impact layout. (This is largely undefined at the moment.) - Figuring out how to best support ol[reversed] list numbering for HTML. i18n-related open issues include: - https://github.com/w3c/csswg-drafts/issues/4209 [syntax for marker-side] - https://github.com/w3c/csswg-drafts/issues/4202 ['direction' on markers] a11y-related open issues include: - https://github.com/w3c/csswg-drafts/issues/4201 HTML-related open issues include: - https://github.com/w3c/csswg-drafts/issues/4181 reversed list decrement - https://github.com/w3c/csswg-drafts/issues/4211 reversed list start value Please review the draft, and send any comments to , prefixed with [css-lists-3] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-lists-3] Updated WD of CSS Lists Level 3
The CSS WG has published an updated Working Draft of the CSS Lists Module Level 3: https://www.w3.org/TR/css-lists-3/ The Lists module covers list-styling options such as changing counter styles and marker position as well as automatic counters and numbering; Level 3 introduces * integration with the new counter styles in CSS Counter Styles L3 https://www.w3.org/TR/css-counter-styles-3/ * additional control over marker positioning * styling via the ::marker pseudo-element introduced in css-pseudo-4 * the new counter-set property * the automagic 'list-item' counter, which allows referencing and manipulating the default list numbers Note in particular that the 'list-item' counter interacts with the automatic numbering features in the HTML spec. See https://www.w3.org/TR/css-lists-3/#list-item-counter This is a significant and overdue redraft of Level 3: some experimental features were dropped and the whole draft has been streamlined and tightened up, shifting the draft from "please don't try to implement this" to "pretty reliable". However, there are still some open issues against Chapter 4 (Automatic Numbering with Counters), and we recommend continuing to use CSS2.1 as the definitive reference for those features until L3 has been fully synchronized with it. Significant changes are listed at: https://www.w3.org/TR/2019/WD-css-lists-3-20190425/#changes-20140320 Many thanks to Mozilla (Mats Palmgren, David Baron, and Emilio Cobos Álvarez) for their detailed feedback this round. Please review the draft, and send any comments to the www-style mailing list, , prefixed with [css-lists-3] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
Re: [whatwg] [CSSWG][selectors-4] Updated WD of Selectors L4
On 11/21/18 2:33 PM, Andrew Fedoniouk wrote: :blank is quite bad as a state name For example shall be considered as not :blank as it has initial value deliberately set to blank string (empty string allowed). This would match :blank. ~fantasai
[whatwg] [CSSWG][selectors-4] Updated WD of Selectors L4
The CSS WG has published an updated Working Draft of Selectors Level 4: https://www.w3.org/TR/selectors-4/ Selectors are patterns that match against elements in a tree and are used as a core part of CSS and in DOM methods such as .querySelector() This update adds, drops, and renames a number of selectors: * zero-specificity pseudo-class named :where() * :matches() renamed to :is() * :blank defined to select empty user input elements * :empty redefined to ignore whitespace-only text nodes * :drop() dropped due to removal of support in HTML * Added case-sensitive attribute value matching flag In addition, the specificity rules for :is() and :nth-child() were altered to use the most specific selector argument rather than the most specific selector that happened to match. See https://www.w3.org/TR/selectors-4/#specificity-rules and discussion in https://github.com/w3c/csswg-drafts/issues/1027 Changes since the February 2018 WD are all listed at: https://www.w3.org/TR/2018/WD-selectors-4-20181121/#changes One major issue that's open is redefining the way invalid selectors are handled within `:is()` and similar pseudo-classes to ignore unknown selectors rather than invalidating the entire style rule. See https://github.com/w3c/csswg-drafts/issues/3264 Another series of open issues concerns the :visited pseudo-class and how to balance security concerns with usability requirements. See e.g. https://github.com/w3c/csswg-drafts/issues/3012 https://github.com/w3c/csswg-drafts/issues/2263 Please review the draft, and send any comments to the CSSWG mailing list, , prefixed with [selectors-4] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-display-3] CR of CSS Display Level 3
The CSS WG has published a Candidate Recommendation and invites implementations of the CSS Display Module Level 3: https://www.w3.org/TR/css-display-3/ CSS Display describes how the CSS formatting box tree is generated from the document element tree and defines properties that control the types of boxes thus generated. New features since Level 2 include: * new two-keyword syntaxes for various display types * inline list-items * run-ins * 'display: contents' to replace an element with its contents The draft also features * A normative description of the CSS box generation model https://www.w3.org/TR/2018/CR-css-display-3-20180828/#intro * Definitions for blockification and inlinification https://www.w3.org/TR/2018/CR-css-display-3-20180828/#transformations * A glossary of key box model terms (largely extracted from CSS2.1) https://www.w3.org/TR/2018/CR-css-display-3-20180828/#glossary Significant changes since earlier drafts are listed at: https://www.w3.org/TR/2018/CR-css-display-3-20180828/#changes Disposition of comments: https://drafts.csswg.org/css-display-3/issues-wd-2017 Please review the draft, and send any comments to the www-style list, , prefixed with [css-display] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
Re: [whatwg] [CSSWG][css-scroll-snap] Updated CR of CSS Scroll Snapping Level 1
On 12/25/2017 02:54 AM, fantasai wrote: The CSS WG has published an updated Candidate Recommendation of the CSS Scroll Snapping Module Level 1: https://www.w3.org/TR/css-scroll-snap-1/ This module contains features to control panning and scrolling behavior with “snap positions”. This update renames the 'scroll-snap-margin' property to 'scroll-margin' and applies it also to the target element of scrolling operations such as scrollIntoView(), focus(), and navigating to #fragment. Note that 'scroll-padding' is already applied generally: https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding A related concern was brought up that some DOM APIs define scrolling to an element in a way that conflicts with scroll-snapping; such APIs should allow for an element's snap position, if defined, to dictate the position of an element to the viewport if no explicit argument is given to the contrary. Significant changes are listed at: https://www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes Sorry, that URL should be https://www.w3.org/TR/2018/CR-css-scroll-snap-1-20180814/#changes ~fantasai
[whatwg] [CSSWG][css-sizing-3] Updated WD of Sizing L3, Last Call for Comments
The updated text regarding intrinsic sizing of replaced elements might be of interest here: https://www.w3.org/TR/css-sizing-3/#intrinsic https://www.w3.org/TR/css-sizing-3/#min-content-zero There's also an open issue about sizing iframes to their content: https://github.com/w3c/csswg-drafts/issues/1771 It's tagged against Level 4, but we did just add handling for and . ~fantasai Forwarded Message https://lists.w3.org/Archives/Public/www-style/2018Mar/0001.html The CSS WG has published an updated Working Draft of the CSS Intrinsic and Extrinsic Sizing Module Level 3: https://www.w3.org/TR/css-sizing-3/ This module extends the CSS sizing properties with keywords that represent content-based "intrinsic" sizes and context-based "extrinsic" sizes, allowing CSS to more easily describe boxes that fit their content or fit into a particular layout context. Significant changes are listed at: https://www.w3.org/TR/2018/WD-css-sizing-3-20180304/#changes and include * merging in the full definitions of all sizing properties from CSS2.1 (min/max?-width/height) and css-ui (box-sizing) https://www.w3.org/TR/css-sizing-3/#specifying-sizes * more thorough definition of replaced element intrinsic sizes https://www.w3.org/TR/css-sizing-3/#intrinsic and percentage sizing within indefinite containers https://www.w3.org/TR/css-sizing-3/#percentage-sizing * defining min-content and max-content to work on form controls * deferring the 'stretch' and 'fit-content' keywords to Level 4 (whose focus will be defining these keywords and 'contain') Open issues include: * Adding more illustrations (help wanted) https://github.com/w3c/csswg-drafts/issues/1938 * Working out how calc() values including percentages work on margins/padding/width/height/gaps when the container size depends on this child box’s size (input wanted) https://github.com/w3c/csswg-drafts/issues/2297 That is, currently when we are calculating the size of the container we treat a percentage size as zero. Then once the size of the container is established, we resolve the percentage against that size. What should happen if we have a size as calc(20% + 10px)? Do we ignore the 10px or honor it in some way? What about calc(10px - 20%)? See https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-sizing-3 for all open issues. We expect to transition to CR soon, so this draft effectively marks the beginning of a last call for comments period; we will be accepting comments at least through the end of March, and depending on the state of the draft, aim to transition to CR sometime in April. (We will of course process comments during CR as well, but would prefer to get them sooner rather than later.) (Note that the min-content and max-content keywords have already been officially cleared for shipping prior to CR by the CSSWG https://lists.w3.org/Archives/Public/www-style/2015Aug/0109.html since their syntax was stable and their behavior was tied to behavior exposed in existing CSS2.1 features.) Please review the draft, and send any comments to this mailing list, <www-st...@w3.org>, prefixed with [css-sizing] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[whatwg] [CSSWG][selectors-4] Updated WD of Selectors Level 4
The CSS WG has published an updated Working Draft of Selectors Level 4 https://www.w3.org/TR/selectors-4/ Selectors is a pattern-matching syntax for identifying sets of elements in a document, and is used e.g. for applying CSS declarations to elements in a document tree. This publication brings the /TR draft up-to-date with all of the WG resolutions since 2013. Significant changes are summarized at: https://www.w3.org/TR/2018/WD-selectors-4-20180201/#changes This specification is now in the Refining stage: we don't expect any large changes prior to CR, but will be continuing to address issues. Most features are well-scoped, with significant open issues described in the draft to solicit directed feedback. One major focus of the next round of edits will be to update and improve cross-references between Selectors and other Web standards (in coordination with the editors of the DOM and HTML standards at WHATWG). If any of you know of other specifications with incoming references to Selectors, please let us know so that we can accommodate them, too! In the meantime, please review the draft. You can send any comments to the www-style list <www-st...@w3.org>, prefixed with [selectors-4] (as I did on this message) or (preferably) file them in the CSSWG GitHub repository at https://github.com/w3c/csswg-drafts/issues We're hoping to address the remaining issues and issue a CR in the upcoming months (but likely not before April). Follow-ups to www-style. For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-scroll-snap] Updated CR of CSS Scroll Snapping Level 1
The CSS WG has published an updated Candidate Recommendation of the CSS Scroll Snapping Module Level 1: https://www.w3.org/TR/css-scroll-snap-1/ This module contains features to control panning and scrolling behavior with “snap positions”. This update renames the 'scroll-snap-margin' property to 'scroll-margin' and applies it also to the target element of scrolling operations such as scrollIntoView(), focus(), and navigating to #fragment. Note that 'scroll-padding' is already applied generally: https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding A related concern was brought up that some DOM APIs define scrolling to an element in a way that conflicts with scroll-snapping; such APIs should allow for an element's snap position, if defined, to dictate the position of an element to the viewport if no explicit argument is given to the contrary. Significant changes are listed at: https://www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes Disposition of comments: https://drafts.csswg.org/css-scroll-snap-1/issues-cr-2016-08 Please review the draft, and send any comments to this mailing list, <www-st...@w3.org>, prefixed with [css-scroll-snap] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 02/02/2017 01:18 PM, Boris Zbarsky wrote: On 2/1/17 6:07 PM, fantasai wrote: Wrt this particular issue, run-ins only run into other blocks; they do not exist in or affect layout modes other than block-and-inline. OK, so if I have a flex container with two kids, a run-in and a block, do I get one flex item or two flex items and why? And did that require any thought about interactions? You get two flex items, because being in a flex container overrides the outer display type of an element: https://www.w3.org/TR/css-flexbox-1/#flex-items In other words, the run-in/inline/block distinction is ignored within a flex container. ~fantasai
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
On 01/26/2017 12:10 AM, Boris Zbarsky wrote: On 1/25/17 10:48 PM, Florian Rivoal wrote: Is it a general argument that adding more things to the platform always makes it harder down the road to add more things due to having to figure out more interactions It's not a general argument in this case. It's a specific argument. For example, adding any new display type has to consider how it interacts with run-in. Adding anything that rearranges things in terms of layout (e.g. shadow DOM, flexbox, grid, etc) has to consider how it interacts with run-in and whether the result makes any sense. Wrt this particular issue, run-ins only run into other blocks; they do not exist in or affect layout modes other than block-and-inline. ~fantasai
[whatwg] [csswg][css-display] Updated WD of CSS Display L3
The CSS WG has published an updated Working Draft of the CSS Display Module Level 3: https://www.w3.org/TR/css-display-3/ This module describes how the CSS formatting box tree is generated from the document element tree and defines the display property that controls it. Additions since CSS2 include * a 'flow-root' value to create a block formatting context root (BFC) * a 'contents' value to discard the element's box but keep its children * inline list items * a 'run-in' layout model slightly less insane than the one proposed in CSS2.0 Significant changes are listed at: https://www.w3.org/TR/2017/WD-css-display-3-20170125/#changes We anticipate this being the last draft before the transition to CR, therefore this is the "last call" for comments. Please review the draft, and send any comments to the CSSWG mailing list, <www-st...@w3.org>, prefixed with [css-display] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[whatwg] [css-display] CSS Display Review
(I'm guessing you don't mind if I forward your comments to the ML. Feel free to scold me for presumptuousness if not. ;) CCing WHATWG for comments on HTML interaction (or any other comments they may have); follow-ups to www-st...@w3.org. On 08/29/2016 06:52 PM, Boris Zbarsky wrote: On 8/2/16 7:38 PM, fantasai wrote: First one is 'display: contents': This one is mostly a question for Mats. That said, I think this feature adds a huge amount of complexity, and I expect that some of its interactions with HTML are not very clearly specced. For example, what should this do: legend and what about: details Text. Note that in Gecko the answer is different for those two cases, more or less by accident. Again, it's not clear to me that either behavior is right or wrong per spec; the HTML spec basically assumes there is no such thing as "display:contents" so its phrasing is ambiguous in the presence of "display: contents", iirc. If we _do_ want to ship this spec, we need to work with the HTML editors to sort out these issues. The HTML spec talks about child elements specifically, not about child boxes. Furthermore its entire spec, except where explicitly noted, is operating on the element tree. Therefore afaict, CSS properties--such as 'display' and its values, whatever they are--should not affect element relationships. I've added some clarifying text to this effect. I expect it's not controversial, but CCing HTML folks in case. :) It's also not 100% clear to me how display:contents interacts with table anonymous pseudos and whatnot. It might be good to make that more explicit (e.g. point out that the replacement in the tree described for display:contents happens before any box generation and box tree fixups or something). Since anonymous box generation takes a box tree and fixes it up, and these elements don't generate a box in the box tree, they presumably don't have an effect on the anonymous box generation. :) Added a note to clarify. Second one is the 'hide' value of the currently-named 'box-suppress': https://drafts.csswg.org/css-display/#valdef-box-suppress-hide If you think this is not particularly useful or urgent, I'll defer it. This seems pretty underspecified. [...] I do think it's useful to have this, but whether anyone ends up using it, I have no idea. If you think it's interesting and useful, please let me know your thoughts on the proposed resolutions to the open issue: https://lists.w3.org/Archives/Public/www-style/2015Jun/0346.html OK, this answers some of my questions above. It sounds like hiding a cell _does_ rearrange which columns other cells are in, yes? What about other interesting layout models (grid, flex, etc)? What are the interactions with those? Since I'm proposing to define it in terms of abspos, the interaction would be as defined for abspos in those modes. Grid and flex, specifically, do not respond at all to containing abspos boxes. Third one is the effect of out-of-flow elements on run-in sequencing: https://drafts.csswg.org/css-display/#run-in-sequence I strongly believe we should not do run-in at all. It's an insane amount of complexity for a super-edge-case feature, as far as I can tell. Of course I've said this for years and it doesn't seem to affect what the CSSWG is up to There remains a demand for the feature, and since we have a *relatively* sane model for it atm, it's been specced for implementer consideration. So far my plan is to spec it insofar as I am able, since it is a feature that's wanted and drop it from the spec if at any point it becomes a burden. On the particular question of out-of-flow elements, I have no opinion, because I haven't really put in the time to consider the implementability of the various options. And given my take on the overall feature I don't think putting in that time would be a good use of my time, sorry. :( Heh, okay. Lastly if you have thoughts on implementability of any options in the discussion of the interaction of run-in and ::first-letter, let me know. https://lists.w3.org/Archives/Public/www-style/2015Feb/0330.html I think anything involving run-in sucks so much to implement and has such low payoff that it should simply not be done. Again, it's not clear to me which of the options here sucks _more_ to implement, but they both suck a lot. Alright. If you have no opinion, then probably the best idea is to leave it undefined until someone tries to implement it... P.S. Fwiw, there are two other open issues, one on syntax: https://github.com/w3c/csswg-drafts/issues/343 No strong opinions. OK And one that is, afaict, a vocabulary issue but may affect something (and probably only dbaron knows): https://lists.w3.org/Archives/Public/www-style/2015Aug/0332.html Looks like a plain bug in CSS2 to me, but I don't have it all paged in well enough to say more... So far no one I've aske
Re: [whatwg] [CSSWG][css-content] FPWD of CSS Generated Content L3
On 06/20/2016 06:14 PM, Phillips, Addison wrote: +I18N Core Thanks for this. I have added this to I18N's radar [1]. Do you have a due date for comments in mind? Or a general schedule? Not really. ~fantasai
[whatwg] [CSSWG][css-content] FPWD of CSS Generated Content L3
Okay, so it's *technically* not a FPWD, but since it's a near-complete rewrite of the 2003 draft, I'm announcing it as one, since it warrants that level of review. :) The CSS WG has published an updated Working Draft of the CSS Generated and Replaced Content Module Level 3: https://www.w3.org/TR/css-content-3/ This is the first draft of a complete rewrite of this module, and is very rough. Major new functionality over Level 2 includes imports from the GCPM module such as: * leaders * target-counters * named strings * bookmark control plus a handy new syntax for alternate text: content: url(sparkle.png) / "New!" We expect future work on this module to be pinning down the actual syntax and behavior of all the exciting new features imported from GCPM. For those who want to toy with implementations, most CSS->PDF renderers already support a significant subset... Significant changes since 2003 are listed at: https://www.w3.org/TR/2016/WD-css-content-3-20160602/ Please review the draft, and send any comments to the archived mailing list <www-st...@w3.org>, prefixed with [css-content] (as I did on this message) or (preferably) file them in the CSSWG GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-pseudo-4] Updated WD of CSS Pseudo-elements Level 4
The CSS WG has published an updated Working Draft of the CSS Pseudo-elements Module Level 4: https://www.w3.org/TR/css-pseudo-4/ This CSS module defines pseudo-elements, abstract elements that represent portions of the CSS render tree that can be selected and styled. This somewhat-overdue publication includes the new ::marker pseudo-class, as well as ::inactive-selection. Changes are listed at https://www.w3.org/TR/2016/WD-css-pseudo-4-20160607/#changes Please review the draft, and either file comments in the CSSWG GitHub repo: https://github.com/w3c/csswg-drafts/issues or mail them to <www-st...@w3.org>, prefixed with [css-pseudo-4] (as I did on this message). For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-cascade-4] Last Call for Comments on CSS Cascading and Inheritance Level 4
The CSS WG has published an updated Working Draft of the
CSS Cascading and Inheritance Module Level 4
http://www.w3.org/TR/css-cascade-4/
This CSS module describes how to collate style rules and assign values to all
properties on all elements by way of cascading (choosing a winning declaration
among many) and inheritance (propagating values from parent to child).
Additions to Level 4 include:
* introduced the 'revert' keyword, which rolls back the cascade
to the previous origin
http://www.w3.org/TR/css-cascade-4/#default
[This had been dropped from L3 due to lack of implementer interest;
but there seems to be strong interest in it at this time.]
e.g. * { all: revert; } /* wipe out the entire set of author-level styles */
* introduced supports() syntax for conditional @import rules
http://www.w3.org/TR/css-cascade-4/#at-import
e.g. @import "fallback.css" supports(not (display: flex));
Since we have no open or anticipated issues, we plan to transition this
module to CR in about four weeks. We do encourage people to review the
draft, particularly the changes since L3, and send us comments.
Significant changes since the previous WD are listed at:
http://www.w3.org/TR/2015/WD-css-cascade-4-20150908/#changes
The editor's draft can be found at:
https://drafts.csswg.org/css-cascade-4/
As always, please send any comments to <www-st...@w3.org>, and please,
prefix the subject line with
[css-cascade-4]
(as I did on this message).
For the CSS WG,
~fantasai
[whatwg] [CSSWG][css-display] Updated WD of CSS Display L3
About a fortnight ago, the CSS WG published an updated Working Draft of the CSS Display Module L3: http://www.w3.org/TR/css-display-3/ CSS Display describes how the CSS formatting box tree is generated from the document element tree and defines properties that control the types of boxes thus generated. Significant changes since CSS2.1 include: * Splitting 'display' into 'display-inside' and 'display-outside' to independently control the layout mode inside the box and its role in the parent formatting context, respectively. * Adding an independent noneness switch that does not overwrite the box type declaration. (This will make it way more straightforward to dynamically show/hide content.) * Reintroducing 'display: run-in', but with more reasonable behavior (as in, you can better reason about it. yay!) * Adding a 'display: contents' value that eliminates the element's own box and brings its children up to act as children of its parent box. * Adding a handy glossary of key terms from CSS2.1 chapter 9. Significant changes since the previous draft are listed at: http://www.w3.org/TR/2014/WD-css-display-3-20140911/#changes We have a couple of key issues open that we would particularly like feedback on: A. Naming of the box-hiding-and-showing property. Please send us suggestions for improvement! (Or comments on what you like about the current name. We're pretty unsure atm, but want it to be easily understandable.) http://www.w3.org/TR/css-display-3/#box-suppress B. Run-in model: we're looking for a review by Boris Zbarsky ;) and also for comments on how best to handle out-of-flow elements between run-ins that form a sequence. http://www.w3.org/TR/css-display-3/#run-in C. Interaction of 'display: contents' and counter numbering: specifically, comments from implementers about the implementability of various options, and comments from authors about how they'd expect the numbering to behave. http://www.w3.org/TR/2014/WD-css-display-3-20140911/#valdef-display-outside-contents D. Figuring out an ideal interaction for the new show/hide switch and its equivalent (the 'speak' property) from CSS Speech. http://www.w3.org/TR/css-display-3/#box-suppress http://www.w3.org/TR/css3-speech/#speaking-props-speak (Likely we'll make 'auto' depend on the value of 'box-suppress', but we're open to other considerations.) Our plan going forward is to 1. resolve all the open issues (obviously) 2. defer the longhands of 'display' to another level [1] 3. hopefully transition to CR in the next six months Please send any comments to the archived www-style mailing list, www-st...@w3.org, and please, prefix the subject line with [css-display] (as I did on this message). Also, please start a new thread; don't reply to this one. [1] It was a good exercise to split them, since we now have a properly combinatorial understanding of how the various aspects of 'display' interact. We plan to split them out again in a future level. But there are combinations--like table cell flex containers--to this that are very difficult to implement atm, and we can disallow at a syntactic level if we retain only the shorthand 'display'. (The show/hide switch, not being a longhand of 'display', will stay separate.) For the CSS WG, ~fantasai
Re: [whatwg] `brand-color` meta extension
On 06/26/2014 12:50 PM, Tobie Langel wrote: On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. It's not the UA's color you're after here, it's the page's own theming color, right? So theme-color or accent-color might make more sense. As a note, an old version of css3-ui used the term 'flavor' for something similar. Unsure about following that precendent. As another note, a request for something similar came up on the CSSWG ML just recently: http://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html In that case it's about retrieving the OS's notion of this color. ~fantasai
Re: [whatwg] several messages about the HTML syntax
On 03/02/2008 03:02 PM, Ian Hickson wrote: On Tue, 31 Jul 2007, Philip Taylor wrote: IE undocumentedly recognises some which nobody else does: aafsU+206D ACTIVATE ARABIC FORM SHAPING ass U+206B ACTIVATE SYMMETRIC SWAPPING iafsU+206C INHIBIT ARABIC FORM SHAPING iss U+206A INHIBIT SYMMETRIC SWAPPING lre U+202A LEFT-TO-RIGHT EMBEDDING lro U+202D LEFT-TO-RIGHT OVERRIDE nadsU+206E NATIONAL DIGIT SHAPES nodsU+206F NOMINAL DIGIT SHAPES pdf U+202C POP DIRECTIONAL FORMATTING rle U+202B RIGHT-TO-LEFT EMBEDDING rlo U+202E RIGHT-TO-LEFT OVERRIDE zwspU+200B ZERO WIDTH SPACE (I believe that list is complete.) The first eleven were suggested on https://listserv.heanet.ie/cgi-bin/wa?A2=ind9605L=html-wgP=4579 some time ago but don't seem to have gone very far (except into IE). I can see some legitimate users at http://www.tasb.com/services/field/staff/index.aspx?print=true and http://www.pelesoft.co.il/ and maybe there's a few dozen or hundred more elsewhere (but I can't measure it easily). There's some in text-art at http://yy28.60.kg/test/read.cgi/maido3/1096370177/l50 and quite a lot in weird places like http://cheese.2ch.net/life/kako/1010/10103/1010391447.html or http://zerosen52.gozaru.jp/log/1093422333.html that I don't understand but that seem to all be on 2channel (or copied from it). I've no idea how common they are in general. Are these used significantly on the web, or would they be considered highly useful if anyone knew they existed, or should HTML5 just ignore them? I'm very skeptical about introducing entities for the codes that are redundant with dir= and bdo (namely, lre, lro, pdf, rle, rlo). I agree 100% with this rationale. I don't know enough about the others to have an educated opinion. I can set up a search to examine the data in more detail. I don't know much about the others, but I can provide some info on ZWSP. It is (as specced) equivalent to wbr. Specifically, it * defines a word break (line-breaking opportunity) * thereby breaks Arabic joining For contrast: ZWSP - Breaks a word (and therefore also Arabic joining) with no visible space. ZWJ - Not a word break. Forces joining behavior. ZWNJ - Not a word break, but breaks joining. ZWJ and ZWNJ are primarily useful for Arabic and other shaped scripts. I'm not sure of the common uses for ZWJ, but ZWNJ is frequently used in Persian to visually separate grammatical prefixes from the rest of the word (without breaking the word or introducing extra space). ZWSP is more likely to be used in Thai and related scripts, to define word boundaries. Thai does not use spaces between words, so break opportunities need to either be marked with ZWSP or found with a dictionary. Even in the presence of automatic dictionary-breaking, however, there are ambiguous cases which will need ZWSP to show the correct break-point. There's further discussion about this in https://www.w3.org/Bugs/Public/show_bug.cgi?id=13108 I've no comment on concerns about compatibility with XML, but I can say that I've typed zwsp; multiple times expecting it to work and find it surprising that zwj; and zwnj; work, but zwsp; does not... ~fantasai
[whatwg] [CSSWG][css-cascade-3] Last Call WD for CSS3 Cascade
The CSS WG has published a Last Call Working Draft of the CSS Cascading and Inheritance Module Level 3: http://www.w3.org/TR/css-cascade-3/ This CSS module describes how to collate style rules and assign values to all properties on all elements by way of cascading (choosing a winning declaration among many) and inheritance (propagating values from parent to child). Notable additions since CSS2.1 include * cascading rules for scoped declarations http://www.w3.org/TR/css-cascade-3/#cascade-scope * full cascade list including transitions, animations, and DOM override rules http://www.w3.org/TR/css-cascade-3/#cascade-origin * the 'all' shorthand to reset all CSS properties http://www.w3.org/TR/css-cascade-3/#all-shorthand * the 'initial' and 'unset' keywords to restore initial state http://www.w3.org/TR/css-cascade-3/#initial http://www.w3.org/TR/css-cascade-3/#unset Significant changes since the last WD are listed at: http://www.w3.org/TR/2013/WD-css-cascade-3-20130730/#changes and include changes to the 'all' shorthand to exclude bidi controls http://www.w3.org/TR/2013/WD-css-cascade-3-20130730/#all-shorthand and the replacement of the 'default' keyword with 'unset' (with different semantics): http://www.w3.org/TR/2013/WD-css-cascade-3-20130730/#inherit-initial (The draft also received a reorg/editorial overhaul.) Please send any comments to the www-style mailing list [1], www-st...@w3.org, and please, prefix the subject line with [css-cascade-3] (as I did on this message). The deadline for comments is ** 26 August 2013 ** Please let us know if you need an extension. We would particularly appreciate review of this module from the HTML and WebAPI communities. Thanks! For the CSS WG, ~fantasai
[whatwg] [CSSWG][css-counter-styles] Updated WD of CSS Counter Styles
The CSS WG has published an updated Working Draft of the CSS Counter Style Module Level 3: http://www.w3.org/TR/css-counter-styles-3/ This spec documents the existing CSS 2.1 and 2.0 counter styles in better detail, adds a handful of CJK and other list styles, and adds an @counter-style rule which allows authors to define their own counter styles. Significant changes since the last WD are listed at: http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/#changes Significant additions include: - the 'width' descriptor for, e.g. zero-filled counters http://www.w3.org/TR/css-counter-styles-3/#counter-style-width - the 'speak-as' descriptor for customizing text-to-speech http://www.w3.org/TR/css-counter-styles-3/#counter-style-speak-as - the 'disclosure-*' styles, intended to be used for the HTML details element and similar use cases http://www.w3.org/TR/css-counter-styles-3/#simple-symbolic We'd especially appreciate a review of these additions. We expect the next step to be Last Call. Please send any comments to www-st...@w3.org, and please, prefix the subject line with [css-counter-styles] (as I did on this message). For the CSS WG, ~fantasai
Re: [whatwg] Media queries for multichannel audio ?
On 03/18/2013 05:18 PM, Mark Watson wrote: Is there anything like this ? I'd like a media element to be able to select the multi-channel version of some audio only when the device will output multiple channels and select a stereo version otherwise (rather than downmixing). This would save network bandwidth as well as providing better quality (if the custom-mixed stereo audio is likely better than the end-device down-mixed version). Seems like this would be handled in the resource selection algorithm by checking if the media attribute of the source matches the environment, but I can't find how to specific audio characteristics in a media query. I don't think such a thing exists, but you could request it for Media Queries Level 4: http://dev.w3.org/csswg/mediaqueries4/ You'd want to post to www-style for that, though. ~fantasai
Re: [whatwg] Styling details
On 04/08/2011 05:05 AM, Lachlan Hunt wrote:
One option is to define that the list-style-type 'disclosure-*' as magic values
that mean to render a UA specific/platform
dependent widget. But that differs from all other list-style-type values and
doesn't seem quite right.
The CSSWG discussed and agreed to add these to the draft back in 2011.
Tab still hasn't edited it in, apparently. *pokes Tab*
http://lists.w3.org/Archives/Public/www-style/2011Apr/0646.html
CSS3-UI, however, uses the 'appearance' property to render native looking
controls.
In theory, native widgets could be achieved instead by using a new 'appearance'
value like:
summary::marker { appearance: -x-disclosure; }
(Assuming the 'appearance' value handles the open/close states automatically,
and any animations that would be expected of
native controls)
The only value of 'appearance' that actually works IIRC is 'none'.
I'm not sure I'd recommend it as a good way forward for anything
since it's not clear how other values are supposed to work.
~fantasai
Re: [whatwg] [html-media-capture] capture vs. accept ( LC-2642)
On 11/16/2012 07:38 AM, frederick.hir...@nokia.com wrote: fantasai Is the WG response (see below) to your Last Call issue (LC-2642) [1] on HTML Media Capture [2] regarding clarification of accept and capture [attributes of input] sufficient for us to close the issue? If timeless and/or hixie are happy with it, I am satisfied. A rough summary is that 1. Accept indicates what is to be captured (e.g. image/*) and Capture indicates the source type, there can be more than one source type for a given 'what' Other than filesystem vs. live (which could be satisfied by a boolean), I don't see how the values of 'capture' are adding any information beyond what can (and should) be provided by 'accept'. 2. Conflict is avoided by precedence rule in the specification that the accept attribute takes precedence over the capture attribute This is fair. I still don't see why you are duplicating the type information, though. As a general design principle, it's better to make it impossible for the user/author to provide invalid combinations than to provide error handling for it. Btw, thank you for your careful tracking of issues: I appreciate your meticulousness in addressing them. ~fantasai [1] https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/2642 representing - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0046.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0047.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0048.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0049.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0059.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0060.html - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0064.html [2] http://dev.w3.org/2009/dap/camera/ (revised editors draft) fantasai wrote: Hi! I was wondering, how is 'capture' different from 'accept'? It seems to me the following are equivalent: capture accept -- camera image/* camcordervideo/* microphone audio/* filesystem */* ~fantasai Working Group Resolution (LC-2642): No changes to the specification are needed, please see http://www.w3.org/mid/50127ec5.2080...@opera.com [[ Not only would this avoid duplication, it also avoids conflicts like input capture=microphone accept='image/*' I believe the spec does address this: The HTMLInputElement interface's accept attribute takes precedence over the capture attribute. That is, if the accept attribute's value is set to a MIME type that is not accepted in a defined capture state, the user agent must act as if there was no capture attribute. ]]
[whatwg] [selectors4] drag-and-drop pseudo-classes
The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. * One for all elements representing drop targets that do not accept this type of item. We'd like comments on a) whether this is a correct and useful set of pseudo-elements b) what these pseudo-elements should be called, that would best (most clearly and succinctly) represent their functionality to authors using them Name sets being considered: Set A Set B Set CSet D :active-drop:drop:current-drop:active-drop :drop :can-drop:valid-drop :valid-drop :no-drop:no-drop :invalid-drop:invalid-drop Thanks~ ~fantasai
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On 08/13/2012 11:55 PM, Ryosuke Niwa wrote: On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.net mailto:fantasai.li...@inkedblade.net wrote: The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. How do we find these elements? On one hand, if we're only supporting dropzone attribute, then adding new pseudo element seems unnecessary. On the other hand, I can't think of ways to detect whether an element could return false or prevents the default action on dragover/dragenter events without firing those events. I don't know. I'm just going on what was asked for in the following thread. :) http://lists.w3.org/Archives/Public/www-style/2011Sep/0402.html The spec prose so far is this: http://dev.w3.org/csswg/selectors4/#drag-pseudos The definition is pretty generic; I'm happy to add details on how exactly it should work with HTML, if someone can provide them. ~fantasai
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On 08/14/2012 03:03 AM, Sebastian Zartner wrote: * One for all elements representing possible drop targets that could receive the item. * One for all elements representing drop targets that do not accept this type of item. This sounds like these two pseudo-classes would do exactly the opposite. So why not use :not() for this case? That question was asked and answered here: http://lists.w3.org/Archives/Public/www-style/2011Sep/0417.html Apparently an invalid dropzone is one that accepts drops, but not of this type, so it's not exactly the same as :not(:valid-drop). I'm unsure if it's necessary to add at this point, but can add it and mark at-risk for the time being. ~fantasai
[whatwg] [css3-flexbox] Going to Last Call
Just as a heads-up, the CSSWG is taking the CSS Flexible Box Layout module to Last Call; all remaining open issues will be refiled as Last Call issues, and the deadline for comments will be 3 July 2012. If you're planning to review, please schedule time accordingly. :) The CSSWG would appreciate comments sent earlier rather than later, since we are racing against some software release schedules. Assuming things go smoothly on the W3C side, the document should be published at http://www.w3.org/TR/2012/WD-css3-flexbox-20120612/ on Tuesday. Until then, you can get a preview at http://dev.w3.org/csswg/css3-flexbox/ Please send any comments to www-st...@w3.org with [css3-flexbox] and the topic of your comment in the subject line. Known issues are being tracked in Bugzilla [1] and discussion is on www-style [2]. Thanks! [1] https://www.w3.org/Bugs/Public/buglist.cgi?product=CSScomponent=Flexboxresolution=--- [2] http://lists.w3.org/Archives/Public/www-style/ ~fantasai Co-Editor, CSS Flexible Box Layout
Re: [whatwg] Why isn't the pattern attribute applied to input type=number?
On 02/10/2012 11:39 AM, brenton strine wrote:
Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
applyhttp://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply
to
the element. (
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
)
Why is it specifically blocked? Doesn't that encourage the use of a less
semantic text input type for numbers that need to be validated beyond
simple max and min?
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern=(\d{5}([\-]\d{4})?)
or you want a US ZIP or ZP4 code which can either be n or n-
pattern=(\d{5}([\-]\d{4})?)
To get the pattern to validate, I have to (non-semantically) change the
input to the text state? I much prefer the current behavior of Firefox
(tested 9 and 10) which does validate the pattern.
As others have explained, zip codes and credit cards are strings composed
of digits, not numbers, and should thus use type=text. If, for example,
you enter '0035', it needs to be processed as '0035' not '35' or '35.00'.
For a number, they are all equivalent. For things like credit card numbers
and postal codes, they probably aren't.
The spec could perhaps benefit from an example of how /not/ to use
type=number here...
~fantasai
Re: [whatwg] di? Please?
On 02/03/2012 12:22 PM, Ian Hickson wrote: On Tue, 10 Jan 2012, Hugh Guiney wrote: As I understand it, the main reason for rejectingdi was that it solves a problem that is allegedly CSS's job, but as an author who uses dls quite extensively, adding a grouping element would really make my life a lot easier. There are a number of places in HTML where it would be nice to be able to group things together -- just look at how often people stickdivs in their pages for no purpose whatsoever other than styling. This shouldn't be necessary. It's a limitation of CSS. The right solution is for CSS to provide some pseudo-element or other mechanism that introduces an anonymous container into the rendering tree that wraps the elements you want to wrap. I don't think this is a CSS problem. I think it's an HTML problem. It's not just that you might want to style definition items, you might also want to tag them with an ID so you can use them as a target anchor. Or pick them up and do interesting things with them via script. But you can't do any of these three things because you can't wrap them in an element. Pseudo-elements are a non-trivial thing to spec, and a non-trivial thing to implement, and a comparatively confusing thing to use. Yet you're suggesting that we use them to solve a problem that is not even entirely solved by a new pseudo-element, rather than defining an appropriate HTML element for the job. So what is it about defining a real element that is so problematic that we're considering a pseudo- element here? ~fantasai
Re: [whatwg] Interaction of wbr and CSS white-space
On 01/13/2012 03:45 PM, Ian Hickson wrote:
On Thu, 15 Dec 2011, Boris Zbarsky wrote [edited for context]:
On 12/15/11 3:10 PM, Ian Hickson wrote [edited for context]:
I might be open to changing the current spec text -- presumably to
just definewbr as follows, or something similar (though using
U+200B would probably affect text selection in a bad way):
nobr { white-space: nowrap; }
wbr { content: \200B; }
nobr wbr { white-space: normal; }
It seems plausible to me; we should run it by Elika.
I asked her on #css but she wasn't around.
I think it's fair to give me at *least* 15 minutes to respond? No? :-)
http://krijnhoetmer.nl/irc-logs/css/20120114
In the interests of moving on with this, I've changed the spec to the
above. I welcome implementation experience on whether this works. If it
doesn't, I'm happy to change it back.
Sounds okay to me.
~fantasai
[whatwg] [css3-images] Last Call Working Draft of CSS Images Values and Replaced Content Level 3
Dear WHAT WG, The CSS WG published a Last Call Working Draft of the CSS3 Image Values and Replaced Content module: http://www.w3.org/TR/2012/WD-css3-images-20120112/ We believe there is some overlap of interest with HTML, and therefore we'd appreciate your review of the features therein, particularly of the element() notation and of the 'image-resolution' and 'image-orientation' properties. http://www.w3.org/TR/css3-images/#element-reference http://www.w3.org/TR/css3-images/#image-resolution http://www.w3.org/TR/css3-images/#image-orientation Those interested in layout and sizing might also be interested in the CSS - image size negotiation rules and the 'object-fit' property. http://www.w3.org/TR/css3-images/#sizing Note that replaced elements in CSS includes not just bitmap images, but also SVG (external or embedded), video, applets, plugins, and other foreign objects. This module covers: - CSS gradients - using media fragments (image slices) in CSS - ltr/rtl annotations to images for automatic flipping - fallback URLs for images, for gracefully handling unsupported image types - element() notation for using an elements' graphical representation as an image - CSS - image size negotiation - 'object-fit' and 'object-position' for controlling aspect ratio preservation - 'image-resolution' for using custom or intrinsic image resolutions - 'image-orientation' to correct misoriented images If you have comments on any part of the draft, please, send them to the www-st...@w3.org mailing list. Please start a new thread for each issue, and include [css3-images] in the subject line, as I did on this message. This will help us track your comments. The official deadline for comments is 7 February 2012. Let us know if you need an extension so that we don't miss your comments. Thanks~ ~fantasai
Re: [whatwg] Interaction of wbr and CSS white-space
On 05/14/2011 12:41 AM, Boris Zbarsky wrote:
On 5/14/11 3:29 AM, Jukka K. Korpela wrote:
For example, when mentioning URLs in the text of a document, you
normally want to prevent line breaks in them by default and only allow
line breaks at specific points, as in
http://www.whatwg.org/wbrspecs/wbrweb-apps/wbrcurrent-work/wbrmultipage/
Oops, my newsreader introduced a line break after a hyphen. And such
behavior is common in web browsers as well. So it is natural to wrap
urls in text in span class=url.../span with CSS rule .url {
white-space: nowrap; }.
Except that browsers don't support that, for the most part.
The problem you describe is one of breakpoint prioritization. I have no problem with
wbr getting priority over breakpoints
that the browser determines itself. CSS3 Text has explicit language to the
effect that not all breakpoint opportunities are
equal in section 7.1.
Anyway, the idea is to disallow line breaks (that would otherwise be
allowed by line breaking rules, whatever they might be in each
situation) _except_ where explicitly allowed by wbr.
This can be done by simply using white-space: normal and having UAs prioritize
breaks at wbr over other linebreaks, no?
Yes, but you'd get unexpected breaks where nowrap isn't used.
IIRC (this is going back 10 yrs) wbr isn't supposed to have
a higher priority than spaces.
The HTML specs cannot dictate what CSS specs do
They're trying to, is my point. As an implementor I then have to reconcile the
conflict somehow. My current plan if it's up to
me is to do so by completely ignoring the part of HTML5 that's conflicting with
CSS here.
I agree that the HTML spec should not be trying to contradict or override
the CSS specs, and suggest that the HTML editor make a habit of posting
such issues to www-style to bring them to the CSS spec editors' attention
instead of merely writing overrides into the HTML spec...
So maybe the best way to convey the message is to remove the reference
to white-space and add a note on the _HTML_ element nobr (even if it
is kept as obsolete - the spec should still specify its meaning):
The wbr element specifies a line breaking opportunity even when used
inside a nobr element.
I would be fine with that, if it's useful. Is it useful?
Yes, if you wanted to control breakpoints, nobr...wbr.../nobr
was very useful.
I think it's possible to deal with the rendering requirements by
specifying
wbr { content: '\8203' /* zwsp */;
text-wrap: normal; }
Slightly off-topic: in CSS3, there is an 'avoid' value for 'text-wrap',
which is designed to solve problems similar to those currently dealt
with by using nobr/wbr combinations.
~fantasai
Re: [whatwg] Interaction of wbr and CSS white-space
On 05/16/2011 06:50 AM, Boris Zbarsky wrote:
another would be adding a new text-wrap value that means exactly that, leaving
it
up to the markup language to identify the allowed breakpoints.
I would prefer not to do this, if it's not necessary.
When I wish to say that characters like the hyphen - and
the percent sign % are not to be treated as breakpoints, as browsers
may treat them by default, what can I do?
Nothing at the moment, but that seems like something to specify via CSS
text-wrap, not via markup.
Actually something to consider for 'line-break: strict', maybe.
Jukka, can you post to www-style about your considerations on
that point? It's rather off-topic here. (Add [css3-text] to the
subject.)
No, because browsers treat a large number of non-whitespace characters
as allowing line breaks after them. Authors need something to prevent
ridiculous and distorting line breaks in, say, -1, %5, and f(1).
OK. I think that something belongs in CSS (or, going out on a limb,
should just be considered a quality-of-implementation issue). This
is not an HTML-specific problem.
CSS3 Text does recommend doing some kind of prioritization when allowing
breaks at punctuation other than spaces, so it is both a CSS issue and
a quality-of-implementation issue. :)
http://www.w3.org/TR/css3-text/#text-wrap
Another thing to ponder: I accept that wbr inside nobr should allow
breaking. Should wbr inside pre allow breaking?
That's an interesting one. I'd have to test like Netscape 4 to find out.
If wbr doesn't break in pre, then it seems the rule we want is either
wbr { content: '\8203' /* zwsp */ }
nobr wbr { text-wrap: normal; }
or
wbr { content: '\8203' /* zwsp */; text-wrap: normal; }
pre wbr { content: none; }
I'm leaning somewhat towards the second option.
~fantasai
Re: [whatwg] Browser full screen and CSS media types
On 05/16/2011 12:02 PM, Andrew Scherkus wrote: While following the other fullscreen thread [1], I remembered there was talk of using a CSS media type for full screen. Mozilla's proposal [2] mentions a new media type @full-screen. Should this in any way extend to browsers that support a chromeless / F11 key full screen mode? Do we care to have any interaction between the full screen API and the browser full screen mode? For example, Opera switches the CSS media type to @projection and I believe is the only browser to do so. I believe the correct list for this discussion would be www-st...@w3.org, with [mediaqueries] in the subject line. ~fantasai
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On 01/24/2011 03:54 PM, Tab Atkins Jr. wrote: Using existing CSS, it's easy to adapt text-shadow to produce a good outline - just make four shadows, offset by 1px in each direction, and you're good. It's been suggested that the spread argument from box-shadow be applied to text-shadow. If implementers want to take that on, it can be part of CSS3 Text. Also there were proposals for a text-outline property, which would do something similar, based on feedback from the TimedText WG. http://www.w3.org/TR/css3-text/#text-shadow http://www.w3.org/TR/css3-text/#text-outline ~fantasai
Re: [whatwg] Making elements match the :active pseudoclass
On 12/28/2010 04:27 PM, Tab Atkins Jr. wrote:
Currently,http://www.whatwg.org/specs/web-apps/current-work/complete/links.html#pseudo-classes
states that the only elements which can receive the :active
pseudoclass are a handful of form elements and any other element which
is specially focusable.
This does not match any current browser. All 5 of the major browsers
allow any element to be :active when clicked. They do differ slightly
on how they determine when an element is :active, though:
* Firefox and Webkit make the target of clicks and all its ancestors :active.
I'll note CSS specs explicitly allow making the ancestors of the
activated element to also match :active.
* IE8 and IE9 make only the target of the click :active
So
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aa%3Aactive%20{%20background%3A%20green%3B%20}%0Aa%20{%20background%3A%20red%3B%20color%3A%20white%3B%20}%0A%3C%2Fstyle%3E%0A%3Ca%20href%3D%22%22%3E%3Cspan%3EClick%20to%20make%20green.%3C%2Fspan%3E%3C%2Fa%3E%0A
does not turn green? That seems pretty broken.
* I'm not 100% sure about Opera's behavior, but it appears that it
finds the first ancestor of the target which would match an :active
rule, and makes that element :active.
That's... interesting.
FWIW, I think the behavior currently in the spec makes the most sense.
If the element has no behavior to activate, it doesn't make sense to
me for the element to ever match :active. And if there is behavior to
activate, it should be keyboard-activateable as well, not just mouse-
clickable.
I'm also interested to know whether there's a web-compat issue here or
just a bug-compat issue, and what the implementers think.
~fantasai
Re: [whatwg] HTML6 Doctype
On 08/29/2010 08:00 AM, Tab Atkins Jr. wrote: On Sat, Aug 28, 2010 at 8:15 PM, David John Burrowes bain...@davidjohnburrowes.com wrote: I agree that they don't have access to versioning info from within the languages. But, CSS has some sense of versions (CSS, CSS2, and CSS3). This gives me some ability to say ah, SurfBrowser 1.0 and 2.0 supported CSS1, but with 3.0 they supported some of CSS2 etc etc. To be honest, no you can't. Not with such large labels, at least. You'll never be able to say X browser supports CSS3, but CSS3 isn't a thing. You can name individual modules only, which is equivalent to naming large features of HTML. How do you define a large feature of HTML? ~fantasai
Re: [whatwg] [Selectors4] Linked Elements, was: required attribute in label
On 08/21/2010 10:23 AM, Christoph Päper wrote:
Someone on wha...@whatwg.org:
This question is sort of CSS related, but I think it's worth bringing up here,
assuming it hasn't already been discussed.
I’m cross-posting to www-style, please follow-up there.
[required]:after {content:*;}
label for=name1Name/label
input id=name1 type=text required
...
There have been discussions about this problem on www-style in the past,
actually.
See http://lists.w3.org/Archives/Public/www-style/2000Jan/0152.html
and http://lists.w3.org/Archives/Public/www-style/2005Oct/0173.html
It's already filed as something to look at for Selectors 4.
~fantasai
[whatwg] bidi embedding for block-level elements
On 01/14/2010 12:49 AM, Simon Montagu wrote: On 01/11/2010 11:35 PM, fantasai wrote: On 11/26/2009 10:54 PM, Simon Montagu wrote: I assume your Gecko example is using a very recent version of Gecko, such as a nightly build or a beta of Firefox 3.6? I fixed this issue only a few months ago. The HTML standard does specify what to do in this case, see http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi: When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element. In practice, however, since browsers are not consistent, authors will have to use CSS properties to achieve the expected results. Does this mean applying unicode-bidi: embed to all block-level elements? Because that seems like it fulfill those requirements. I was thinking in terms of applying unicode-bidi: embed ad hoc whenever applying display: inline to a specific element, but applying it wholesale to all block-level elements will also work, of course. In that case, I suggest the we add it to the sample default style sheet for HTML 4 in the CSS2.1 appendix, and recommend the HTMLWG add some wording about block-level elements defining bidi embedding boundaries to the HTML5 spec (and perhaps using CSS's unicode-bidi: embed rule as an example). ~fantasai
[whatwg] table 'frames' attribute
Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
contains some style rules for handling the [rules] and [frames] attributes
of the table element. I haven't reviewed it all in detail but this part
table[frames=void] tr td, table[frames=void] tr th,
table[frames=above] tr td, table[frames=above] tr th,
table[frames=below] tr td, table[frames=below] tr th,
...
table[frames=border] tfoot tr td, table[frames=border] tfoot tr
th {
border-style: solid;
}
is certainly wrong both per spec (HTML4) and implementation. It should be
removed. Also, you probably want to track Mozilla bug 43178 for this section
https://bugzilla.mozilla.org/show_bug.cgi?id=43178
since we are actually planning to implement these attributes with CSS rules
unless we hit performance problems with that approach.
There's a collection of tests for these attributes here:
http://fantasai.inkedblade.net/markup/tests/table-frame-rules/
I should probably expand it to include tests for the empty string and junk
valuse, but that's what it is for now.
~fantasai
Re: [whatwg] table 'frames' attribute
Ian Hickson wrote:
On Mon, 4 May 2009, fantasai wrote:
Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
contains some style rules for handling the [rules] and [frames] attributes
of the table element. I haven't reviewed it all in detail but this part
table[frames=void] tr td, table[frames=void] tr th,
table[frames=above] tr td, table[frames=above] tr th,
table[frames=below] tr td, table[frames=below] tr th,
...
table[frames=border] tfoot tr td, table[frames=border] tfoot tr
th {
border-style: solid;
}
is certainly wrong both per spec (HTML4) and implementation. It should be
removed.
Could you elaborate on how it is wrong?
Yeah, sure.
http://www.w3.org/TR/html40/struct/tables.html#h-11.3.1
This attribute specifies which sides of the frame surrounding a table
will be visible.
It's not supposed to create any internal borders, just affect the borders
of the table itself. By contrast the 'border' attribute does create
internal borders, but you can see that called out specifically later in
that section.
~fantasai
Re: [whatwg] Selectors Tests and :enabled
Ian Hickson wrote: On Wed, 11 Feb 2009, fantasai wrote: Given the state of current implementations and the fact that hidden input elements do have distinct enabled and disabled states, I don't understand the reasoning behind this change. http://twitter.com/WHATWG/status/1198455588 The idea was to match Selectors. ... I see this has now changed. I will update HTML5 in due course to match the new text in Selectors. (I'll also update my spec index to point to the dev.w3.org link instead of the /TR/ page so that I don't make this mistake again.) Ok. I'll ping you once we publish a new draft (which, hopefully, should be within a week or two). ~fantasai
Re: [whatwg] Thoughts on HTML 5 - dialog
Ian Hickson wrote: On Tue, 13 May 2008, Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? Of course most people using these elements won't be reading the spec. It is quite likely that someone will assume dialog is the correct tag to use for a CSS+JS dialog box. ~fantasai
Re: [whatwg] The dialog element and related topics
to indicate that a part of the page was used as a dialog rather than part of the normal content flow. ... You could use dialogue instead of dialog. Dialog is an alternate spelling of dialogue in common English, but IIRC dialogue is never used for dialog boxes. I'm sure mpt can correct me if I'm wrong... ~fantasai
Re: [whatwg] Text APIs on canvas
Ian Hickson wrote: The idea is that only scalable (vector) fonts should be used, since otherwise things will quickly look ugly. I've made the spec require this. Going forward the spec is likely to require effects such as adding text to paths, which will require vector data for all fonts used anyway. I don't want to mislead implementators into thinking bitmap fonts are in any way an option in this day and age. Just fyi... IIRC, Chinese and Japanese fonts often have to use bitmaps for smaller pixel sizes. Shrinking the vector wouldn't be clear enough for high-density characters: in many cases certain carefully-chosen strokes are left out in the smaller sizes in order to make it legible. Judging from information about Meiryo, it seems more recent font technology uses vectors + hinting to solve the same problem... but maybe it's something to keep in mind. ~fantasai
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak wrote: By contrast, I do not know of any actual need to determine the aspect ratio of an SVG icon or the duration of a sound icon. I do not know of cases where HI guidelines for particular platforms would recommend different choices of icon aspect ratio or sound icon duration. Thus, I suggest we limit ourselves to adding only the info that is actually known to be needed at this time. If UI innovation creates a need for more info, we can add it to the spec then. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. ~fantasai
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak wrote: OK, I'm sure the last thing that is needed is more syntax suggestions, but here's an alternate proposal with no new attributes, specify size info as additional rel keywords: link rel=icon scalable type=application/svg href=whatwg.svg link rel=icon 16x16 32x32 type=image/microsoft.vnd.icon href=whatwg.ico link rel=icon 16x16 32x32 64x64 128x128 256x256 512x512 type=image/x-apple-icons href=whatwg.icns link rel=icon 59x60 type=image/png href=whatwg.png This would however effectively define an open-ended set of rel values, and also it is dubious whether a size can be considered a relationship. I don't think it can. This seems pretty wrong to me: the right place for this information would be, as Jeff Walden said, in the 'type' attribute. ~fantasai
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak wrote: This might require that existing browsers cope correctly (or exploit duplication/error behaviors), but could a MIME parameter address this without needing another attribute at all? That's the most narrowly scoped change I can imagine that would address the need. link rel=icon type=application/svg; sizes=any href=whatwg.svg link rel=icon type='image/microsoft.vnd.icon; sizes=16x16,32x32' href=whatwg.ico link rel=icon type='image/x-apple-icons; sizes=16x16,32x32,64x64,128x128,256x256,512x512' href=whatwg.icns link rel=icon type=image/png; sizes=59x60 href=whatwg.png Restrictions on what a parameter value may be (basically can't contain any separators or whitespace) are a touch confounding here because you don't have any separators unless you quote; that probably factors into the equation here. I'm not against using a MIME parameter per se, but it would have to be x-prefixed (unless we register it) and I'd strongly prefer a syntax that does not require use of nested quotes. If I'm reading the spec correctly http://www.faqs.org/rfcs/rfc2045.html you could use '+' as a separator. sizes=16x16+32x32+64x64 For SVG icons, you'd probably want the ability to specify a ratio instead. (And I suppose for sound icons, you'd want the length of the sound clip...) Also, I didn't see anything in the spec about parameters needing to be prefixed, only subtypes. Maybe I missed it. ~fantasai
Re: [whatwg] Proposal: target=_reference
Křištof Želechovski wrote: How about target=_guide instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Or _notification. Most of what Matthew wants to use it for seems to be notifications. How are you supposed to figure out the size of this thing? If it's for footnotes and TOS and errors and help and what's-this all at once.. they have different layout requirements. Footnotes fit fine at the bottom, but notifications should be at the top. Small help content could be anywhere, but extensive help content would fit better on the side, especially on wide screens. Squeezing significant amounts of text content into a top or bottom panel would make it hard to read: that space is wide and short. And TOS pages need more space than any of these if you're actually planning to read them, but they don't need to be side-by-side with the original page: in that case a floating box in the middle of the page would be ideal. Etc. ~fantasai
Re: [whatwg] Lowercase attribute values
Ian Hickson wrote: On Mon, 29 Aug 2005, Henri Sivonen wrote: On Aug 28, 2005, at 09:56, Henri Sivonen wrote: How should the lowercasing be performed? Using the locale-insensitive Unicode case data or for ASCII only treating non-ASCII as an error? On further reflection, it seems to me the latter has to be chosen at least for a parser that is intended to be used as a part of a conformance checker. Otherwise input type=RADİO ... would pass. Good point. Ok, ASCII-only it is. Can't find this in the spec atm, maybe it's on your to-do list. You need to define what case-insensitive means. For some background, you can see the relevant discussions for CSS http://www.w3.org/blog/CSS/2007/12/12/case_sensitivity ~fantasai
Re: [whatwg] several messages about quotations
Ian Hickson wrote: Summary: I've made the spec require that any punctuation for q be included inside the element; I've added examples for q. ... How would you define CSS pseudo-elements for open and close quotes in such a way that they would be implementable and would not match apostrophes and would correctly differentiate between open and close quotes in languages that use the same character for opening and closing and in languages that invert the direction of guillemets compared to French? I would introduce two pseudo-elements, ::quote-start and ::quote-end, which match one or more characters with the Quotation_Mark property (as per Unicode PropList) found at the start or end of an element, if such text is a direct child of the element (skipping White_Space characters). I've started this idea down the path of the CSS working group. Please send a message with your proposal to www-style for discussion and CC www-international. (We use the wiki to track issues, not as a substitute for mailing list discussion. Also, it would be important to have i18n people involved since punctuation styles vary across languages and I'm not sure Unicode's Quotation_Mark property is adequate.) ~fantasai
Re: [whatwg] Scaling
Nikola Mitic wrote:
fantasai wrote:
Michael wrote (on www-style):
I have a fluid layout so it changes width because of the browser window.
There is the slight problem that some of the images I use might be too wide.
So I use max-width:100% to prevent this from happening. This works great
when the image does not have a width or height attribute set. The image
remains in proportion. (...) But if the height attribute is set, it retains
this height and the image goes out of proportion.
I think we need some property for this (...)
Set img { height: auto; } and your images should size proportionally.
Is there any way to prevent page from being pushed down by image height
when full image get loaded if we didn't define exact image height?
Depends on the situation. You can put a container around the image that has a
fixed height, but it will leave extra space if the max-height: 100% kicks in.
If HTML5 defines the 'width' and 'height' attributes as suggesting the intrinsic
size of the image, browsers could use that information to calculate a tentative
aspect ratio. That would make it possible to size the unloaded-image box even
when one dimension is auto.
~fantasai
Re: [Whatwg] Request for HTML-only print link
Sander wrote:
Hello,
I'm not sure whether this has been requested before, but the link to the
archives of this list seems to be broken at the moment, so I give it a
try...
I'd like to see an extension of the hyperlink to give it an HTML-only
print function. Nowadays making a print link available from within a
website always involves client-side scripting. This dependency should
not be necessary for something like printing as it is basic
functionality in most browsers (not sure about mobile devices though).
Websites shouldn't need to have a print link, they should provide a print
style sheet with link rel=stylesheet media=print src= UAs should
be automatically applying the print style sheet when printing.
.all .irrelevant .navigation .and .advertisement .classes {
display: none;
}
* {
background: white !important;
color: black !important;
}
should do the trick on a lot of sites if the author just bothers to put
it there. Of course the author could make the print result pretty, rather
than just a text dump. There are very few cases where a separate document
would be necessary.
~fantasai
Re: [whatwg] Pre-defined classes and conformance
Henri Sivonen wrote: When an author uses a new class name not defined by either this specification or the Wiki page, conformance checkers may offer to add the value to the Wiki, with the details described above, with the proposal status. It has been pointed out to me that the offers would drive developer crazy. That and you'd get tons of thoughtless registrations by people trying to get the conformance checker to shut up. Defining rel values makes sense. They're only used if the author wants a specific behavior. Class values, on the other hand, whether or not they're used with semantics in mind, their primary purpose is as a style hook. They're the utility knife of the web design world. They're used not only for semantically organizing page elements, but also as ways to hang decorative images, tag elements for scripting, and work around innumerable browser bugs and limitations. Trying to constrain their use is imho unwise. When Tantek Çelik comes to the WHATWG or the HTMLWG and says I want a central registry for class names, then make one. Until then, I suggest simply leaving this domain to the μF guys (and gals). ~fantasai
Re: [whatwg] Should address be more general-purpose?
Benjamin Hawkes-Lewis wrote: An author element might kill several of these birds with one stone. I'd rather see an attribution element than an author element. It is more generally useful. ~fantasai
Re: [whatwg] article: do we really need this?
Elliotte Harold wrote: Not much. section class=article is perfectly fine. My mind just happened to be in another spec at the moment where there were roles and not classes, so I happened to mention role where I probanly should have said class. IMHO, predefined classes do not belong in HTML5. The class attribute is already defined as user-defined, and it should remain that way to avoid conflicts. It's not really a question of whether article makes sense. The question is whether it makes *enough* sense. There are arguments for it, but they're very weak. I do not see a community crying out for this. I don't think it's going to help anybody all that much, and I'm afraid it's going to end up like address: a poorly understood, rarely used element that's misused more often than it's used properly. address is a poorly understood, rarely-used element because it's poorly-named. It represents the intersection of contactinfo and attribution, which is neither particularly useful nor particularly related to its name. I suspect I could ask the same question of a few other elements as well. time and meter come to mind. They at least don't have any obvious equivalents already in the spec, and are obvious enough they perhaps won't be frequently misused; but do authors actually need these? Will they use them? The meter concept is widely used already (think reviews and ratings). As long as meter provides the necessary stylistic flexibility, it should be a useful addition to HTML5. If it doesn't, though, or if it makes styling more difficult than current methods, then it won't be used much. Dates are very often marked-up specially.[1] There's even a microformat design pattern developed to embed ISO representations of the date without compromising its readability: http://microformats.org/wiki/datetime-design-pattern The time element is much more appropriate for this than abbr. [1] http://code.google.com/webstats/2005-12/classes.html ~fantasai
Re: [whatwg] article: do we really need this?
Elliotte Harold wrote: Has there been any extensive discussion of the article element in Web Apps 1.0? It is currently described as: represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content. It seems sort of wishy washy. Most of the time what I think of as an article is a separate page with its own URL. This use case seems to be handled better by section, perhaps with a role attribute. Maybe a section is less independent than an article, but that's going to be a very fuzzy distinction, and really hard to explain, teach, and validate. Is there some obvious use case for this element? Mostly to me it just seems to needlessly clutter the spec, especially once you consider how it relates to potential sibling sections. I think I'd prefer to just drop it and stick with section. This element would be extremely useful to someone with a screen reader. It would create an implied UA hook for skip to main content, for one. With multiple postings within a page, it would create a reliable way of skimming the main sections (by reading the first bit of content on each posting), even when there are no headers or when the postings themselves have internal sectioning and headers (especially if those are inconsistent). For printing, the article element would make it easy to cut out extraneous content and print just the main content of a web page. ~fantasai
Re: [whatwg] contenteditable, em and strong
Henri Sivonen wrote: On Jan 9, 2007, at 23:29, Benjamin Hawkes-Lewis wrote: Henri Sivonen wrote: I think using span with a style attribute is a bad idea in this case. Italicizing a word or two in a paragraph is not incidental style that could easily be considered optional. Surely it /is/ an incidental style, since authors, publication houses, and style guides vary in their preferences about when to italicize. Surely it is the distinctions between foreign and native languages, between emphasis and non-emphasis, between titles and non-titles, and so forth, that are non-incidental, and that italicization imperfectly reflects. The typography is not the message; it is only its shadow. Granted, but italics and bold are more sticky properties of the text than e.g. font family, font size or column width, so it is a mistake to treat all style properties as being equally incidental and expendable. It is a more essential part of the text that should be preserved when the content is formatted for a different display environment possibly with a different font. How would a different font conflict with its italicization? It wouldn't. My point was that italic and bold are stickier or closer to being part of content than the font. That depends, actually, on the language. Browsing the Chinese journal section of a university East Asian Library, I noticed that the Chinese journals didn't use normal/italics -- instead they switched the style of font between their equivalents of serif and cursive. Granted these switches were on a per-paragraph level in the text I saw, but East Asian typesetting tends not to use italics in general. They have other means of indicating emphasis: various underlining styles, bold, (in Japanese) a switch to katakana, and emphasis marks which are placed above/below/beside individual characters in an emphasized phrase. East Asian texts also don't use italics for works titles: they have a set of special punctuation for that. You can argue that italics and bold should be strictly equivalent to em and strong because all that matters is that their presentation is the same, but that argument doesn't hold up for non-Latin texts. Restyling em sitewide to use 'text-emphasis' instead of 'font-style: italic' would be a nifty thing on a Japanese website. Restyling i the same way would just be silly. ~fantasai
Re: [whatwg] Ruby markup - Furigana Re: Presentational safety valves
Henri Sivonen wrote: On Jan 4, 2007, at 12:05, Karl Dubost wrote: Le 4 janv. 2007 à 18:41, Henri Sivonen a écrit : It doesn't matter much. It is rather clear that the ruby markup is intended for a particular Chinese and Japanese typographical device. You'd use the markup whenever you want to use that typographical device. Bothering authors with what they profoundly mean when they use the typographical device isn't particularly helpful. Furigana is an annotation system. And essential for learning the language at school. Or read the kanjis that are too difficult to be known when browsing. Right, but my point is that authors will use the ruby markup when they want the furigana typographic effect. It isn't helpful to insist on a particular semantic scope like, for example, requiring the ruby base to be considered difficult kanji. Right. I have even seen cases where ruby is used to annotate English words (base) with Japanese Kanji (ruby): http://fantasai.inkedblade.net/style/discuss/directions/scans/genji2 Ruby is a nifty annotation system if you want to mark up words in parallel, as for pronunciation, or word-by-word translation, or grammatical labelling, etc. The key difference from other annotation systems is that it can be word-for-word without being awkward. (Imagine doing this with footnotes.) ~fantasai
Re: [whatwg] PaceEntryMediatype
Mark Baker wrote: The real problem here AIUI - at least in the context of HTML 5's inferred rel=feed bit - is not just entry documents, it's any Atom document which wouldn't normally be considered a feed by a typical user; something that most people would be interested in subscribing to. An example I gave on the whatwg list was an MHTML-like (MIME multipart) package, but there are many other possible examples of course; not all RFC 4287 feed documents are feeds in this sense. If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. Note that HTML 5's special handling of alternate+Atom is triggered on a literal value for the 'type' attribute: # If the 'alternate' keyword is used with the 'type' attribute set to the value # 'application/rss+xml' or the value 'application/atom+xml', then the user # agent must treat the link as it would if it had the 'feed' keyword specified # as well. That means rel=feed won't be implied on an Atom Entry document whether the new MIME type syntax is chosen to be application/atom.entry+xml or application/atom+xml;type=entry It also won't be implied on an Atom feed document if the syntax application/atom+xml;type=feed or application/atom+xml;type=archive is used, as was suggested earlier. This gives us a way to say link rel=alternate href=[..] type=[atom] without implying link rel=alternate feed href=[..] type=[atom] and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai
[whatwg] WA1: Link type index
I believe the 'index' link type definition isn't quite right, considering prior definitions of the term[1]. It seems to me that 'index' would be more appropriate, given its prior definitions, for linking to things like CSS2.1's list of properties (Appendix F). http://www.w3.org/TR/CSS21/propidx.html I think that for the hierarchical root, 'top' (which was defined in HTML 3.2) is more appropriate, both historically[2] and by virtue of its English semantics. I also think that 'contents' and 'toc' should not be equated with 'top' because they are not always the same thing. I would expect 'toc' or 'contents' from http://developer.mozilla.org/en/docs/Gecko_DOM_Reference to link to http://developer.mozilla.org/en/docs/Gecko_DOM_Reference but 'top' to link to http://developer.mozilla.org/ , i.e. the homepage of the website. [1] http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html#index [2] http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html#top ~fantasai
Re: [whatwg] PaceEntryMediatype
Thomas Broyer wrote: There's no need to fetch every link if you base your assumptions on the type= attribute (and *only* the type= attribute, not the combination with any special rel= attribute value). How does this solution deal with, e.g. hAtom? http://microformats.org/wiki/hatom The content type does not help you there. Some other meta-information is necessary. Fair enough. They still exist, though. Browser vendors aren't going to stop supporting this. We would be just sticking our heads in the sand if we ignored this. Many things are marked as deprecated in earlier HTML versions, and are still supported by browsers. Also, as the misuse of rel=alternate is not machine testable, and given that I don't propose banning the use of rel=alternate for feed autodiscovery, I can't see how a browser vendor could stop supporting this. I agree that misusing alternate to link to feeds that are not an alternate representation of the page should be non-conforming. Of course yes, and they will be discovered based on the content-type, and rel= will deserve its real role: describing the relationship between the two resources (and not describing the other end of the link). I agree that the feed link type is not /quite/ a proper link type-- it's more of a meta-content-type--but I've come to conclusion that the problem it solves, and how neatly it solves it, eclipses this (subtle) semantic distinction. Definition of feed: a bag of items; the representation of a feed generally exposes only the 10, or so, latest created or updated items. You'll note that this has nothing to do with the feed format (Atom, RSS, a Web log's homepage in HTML, etc.) If a document was once linked from a feed's representation as an item, it is an item of this feed, even if the feed's current representation doesn't link to it anymore. The relationship still exists. This relationship is I am an item of this feed or this is a feed within which I once appeared. I propose representing it as rel=feed. ... Anyway, if you link to something, there's a reason. This reason is that there is a relationship between the current document and the thing the link points to. This relationship is described in the rel= attribute. It is *a* feed is not a valid reason, it doesn't describe a relationship. This is an alternate representation of this page in a format you can subscribe to is a valid reason: it's an alternate representation. I am an item of this feed is a valid reason: I was once linked from it, so you'll find other similar things you might be interested in (because they are from the same author, or about the same subject, etc. this is to be explained to the user using the title= attribute, that's not something a machine has to know about). That's an interesting relationship. Perhaps it could be expressed as index feed within the context of WA1.0's current link type definitions. In any case, I would like to see this use case definitively addressed. Such a link would be the most appropriate default feed to subscribe to from an entry page, if it were somehow clearly labelled. ~fantasai
Re: [whatwg] Editorial: dfn s/term given by the contents/term/
Simon Pieters wrote: Hi, The dfn element: The dfn element represents the defining instance of a term. The paragraph, definition list group, or section that contains the dfn element contains the definition for the term given by the contents of the dfn element. Given the definition of defining term two paragraphs later, the term of the dfn element is not always the contents of the element. I suggest replacing the above text with: The dfn element represents the defining instance of a term. The paragraph, definition list group, or section that contains the dfn element contains the definition for the _term_ of the dfn element. I'd just strike the contents. definition for the term given by the dfn element. ~fantasai
Re: [whatwg] many messages regarding image captions
Michel Fortin wrote: To me, a figure contains illustrative content attached to a document. It may be an image, a code sample, or a snippet of another document used as an example. I think it's important we do not try to narrow too much what can and what cannot be contained in a figure; that's the job of the author do decide. For instance, lets say an author wants to put a paragraph in a figure. It could be to show how the font is rendered, in which case he may prefer to use a pixel or vector image because what is important is the shape of the characters; it may be to show a particular writing style, in which case it's much better to provide the paragraph as text directly as the text itself is the illustration. In any case, the author knows what he wants to illustrate, and we should allow him to use the best medium for that task. Some examples of this kind of usage, albeit without the captions: http://www.mozilla.org/contribute/writing/markup#notes ~fantasai
Re: [whatwg] Table integrity and conformance
Lachlan Hunt wrote: scope= will probably only be allowed for THs. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). Maybe. I think the spec should explicitly define how to determine which header cells are associated with each cell. IIRC, the HTML 4 spec does define an algorithm like that, so maybe it could be improved. The HTML 4 spec says to use TD for a cell that functions both as data cell and an header cell. [1] For these cases, it would be necessary to allow scope on TDs. [1] http://www.w3.org/TR/html40/struct/tables.html#h-11.4.1 ~fantasai
Re: [whatwg] Table integrity and conformance
Henri Sivonen wrote: On Oct 27, 2006, at 16:21, Anne van Kesteren wrote: On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? http://www.w3.org/mid/[EMAIL PROTECTED] [1] http://www.w3.org/TR/CSS21/tables.html#q7 WHOA! How on earth did that end up in a CSS WG draft in general and in the CSS 2.1 draft in particular? Easy: it didn't get removed. http://www.w3.org/TR/CSS2/tables.html#q7 ~fantasai
Re: [whatwg] Table integrity and conformance
Michel Fortin wrote: Sometime, presentational information is needed to display a document correctly, and in those few cases where the presentation is tied to the content, I think it belongs in the markup. The align attribute, when used on table cells, covers one of those cases. I think that is a stronger argument for keeping char than align. Another argument for align is that CSS alone can't do anything useful about alignment in columns, since inheritance only works through the element tree. Of course, I'd prefer to see that fixed in CSS. ~fantasai
Re: [whatwg] Simple numbers
Anne van Kesteren wrote: Quoting Michel Fortin [EMAIL PROTECTED]: Maybe a number element would be valuable, both inside and outside formulas, to provide format-neutral machine-readable numeric values: n value=123456789.12123 456 789,12/n So the machine can just infer the format inside from the locale. What locale? ~fantasai
Re: [whatwg] image captions
Alexey Feldgendler wrote: On Thu, 06 Apr 2006 06:59:15 +0700, Michel Fortin [EMAIL PROTECTED] wrote: aside h1Figure 1: Some image found a href=...here/a/h1 pimg src=.../p /aside I'm afraid this won't degrade gracefully: the h1 would confuse the document outline facilities in today's user agents. You could use h6. Just always use h6 for the figure caption. Actually, I think WA should generally allow the use of h6 as a terminal-level header, similar to the simplesect element in DocBook. It's a useful markup construct sometimes, at least in my experience. ~fantasai
Re: [whatwg] image captions
Ian Hickson wrote: On Tue, 4 Apr 2006, fantasai wrote: I'm wondering what WA1 considers appropriate markup for a figure with a caption. pimg src=image-equivalent-of-text alt=text title=caption/p As Lachlan points out, putting caption text in an attribute isn't very good design and it gets in the way of a lot of things: marking up the text, styling it without having to be a web tech expert of your caliber, etc. The alt attribute has similar problems, but at least there we have object as an alternative. ~fantasai
Re: [whatwg] id and xml:id
Henri Sivonen wrote: I have now assessed the damage. It is not as bad as it looked like. :-) Despite a flood of error messages, there were only three causes: 1) Can't have wild card attributes on wild card elements in the wild card content models of the script and style elements. (Not a big deal. It is reasonable to restrict them to known style and script languages.) That seems odd. You should be able to say the content model of this element is anything. http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-2.html#relax-CHP-12-SECT-2.1 2) Jing complains about the IDREFness altering co-occurrence constraint between valuetype and value on the param element. 3) It appears that in RELAX NG an attribute can't be allowed to take the empty string if the attribute has the IDREFS nature. This is a problem with the form attribute. See: http://groups.yahoo.com/group/rng-users/message/422 Does moving the choice up higher help any? ~fantasai
Re: [whatwg] id and xml:id
Henri Sivonen wrote:
Since UAs handle whitespace in the id attribute inconsistently (see
below), old specs imply or require whitespace trimming and ids with
whitespace are unreferencable from whitespace-separated lists of ids, I
suggest adding the following language concerning document conformance:
The value of the id attribute must be a string that consists of one or
more characters matching the following production: [#x21-#xD7FF]|
[#xE000-#xFFFD]|[#x1-#x10] (any XML 1.0 character excluding
whitespace).
I'd rather see the id attribute restricted to an NCName token insofar
as possible. We can make an exception for Hixie's repetition templates,
but otherwise I think it should be compatible with the XML ID syntax.
So
xsd:id {
pattern: \S*;
}
The concept of idness is a useful one for many tools, and even if
browsers don't care what characters there are, other tools do. We can't
express IDness in a schema if we insist on ignoring its syntactic
restrictions.
~fantasai
Re: [whatwg] id and xml:id
Henri Sivonen wrote:
On Apr 2, 2006, at 18:56, fantasai wrote:
I'd rather see the id attribute restricted to an NCName token insofar
as possible. We can make an exception for Hixie's repetition templates,
but otherwise I think it should be compatible with the XML ID syntax.
Do you mean common attrs should have a co-occurrence constraint that
changes the datatype of the id attribute if the repeat attribute is
present?
Yes. Or, at the very least, if the repetition module is loaded.
I was planning on defining the datatype of the id attribute as
xsd:string {
pattern = \S+
}
NCName with the exception that it allows [ and ] will be one huge
regexp. (But doable, of course.) If that is what we want, the syntax
should probably be
(Letter | '_') (NCNameCharWithout02D1and00B7)* (('[' | #x02D1) (
NCNameCharWithout02D1and00B7)+ (']' | #x00B7)))? (
NCNameCharWithout02D1and00B7)*
with the XML 1.0 definitions of Letter and NCNameChar.
Cool, that would even catch mismatched brackets. :)
The concept of idness is a useful one for many tools, and even if
browsers don't care what characters there are, other tools do. We can't
express IDness in a schema if we insist on ignoring its syntactic
restrictions.
I didn't bother to make that argument, because I thought changing the
language to fit schemas wouldn't go down well with Hixie. :-)
(In http://hsivonen.iki.fi/lists-in-attributes/ I tried to bring a
general less code and more reuse of correct code argument into it
instead of only playing the it's incompatible with my schema language
of choice argument.)
It's not my schema language of choice, it's the top three (by a long
shot) schema languages in use for XML.
I wasn't even expecting to be able to do IDREF integrity checks in
RELAX NG. I was planning on doing it in Schematron or Java. Besides,
general IDREF integrity checking does not check that, for example, the
form attribute references only form elements and not just any ids.
I would want that in the RelaxNG schema because there are editing tools
that hook into RelaxNG, but not many (or any besides validators) that can
hook into Schematron (Glazou, for example, is working on a RelaxNG-driven
editor.) RelaxNG /can/ do IDREF integrity checks. The part about form
attributes referencing only form elements can be checked by Schematron.
From an authoring standpoint, the *most* useful part of IDREF integrity
checking is to check against typos, not against misinterpretation of the
idref attribute's intent. :)
~fantasai
Re: [whatwg] Select conformance
Henri Sivonen wrote: Single select: Is it conforming for an option to be both selected and disabled? (I think it shouldn't be conforming.) I agree with that. And analogously: Is is conforming for a radio button to be both checked and disabled if the whole set is not disabled? (This one is harder to check, but anyway...) No, I think it should be allowed. There are some cases where, e.g. some previous option you picked forces certain other checkboxes either on or off. They're disabled because you can't change them, but, some of them might need to be on. Is it conforming to have no option that is marked selected? (I think allowing this is safe.) It is. User agents implementing this specification must select the first (non-disabled) option element of a single-select select element with no otherwise-selected items. Hixie would have said something about it being nonconforming to have no selected options at that point, and wouldn't have had multiple examples of selects with no selected options, if that was what he meant. ~Elika
Re: [whatwg] progress draft
Ian Hickson wrote: On Tue, 28 Mar 2006, fantasai wrote: Another issue is the possible use of U+2212 MINUS SIGN intead of U+002D HYPHEN-MINUS. This last, at least, should be handled whenever the number is parsed from the text content rather than in an attribute. In the text, negative numbers aren't supported (if you use the fallback to source the numbers, the minimum is fixed to 0 and the maximum must be greater). Not for progress, but for meter, you should be able to. # Note: The meter element should not be used to indicate progress (as in a # progress bar). For that role, HTML provides a separate progress element. I think this should be normative. ~fantasai
Re: [whatwg] A better name than gauge for the element that shows a measurement
Christoph Paeper wrote: I'm not a native speaker and would have written it correctly. OTOH I never would have imagined the alleged AE spelling 'gage' [LEO], because I would pronounce that completely different: /gO:Z/ vs. /geIdZ/ [SAMPA]. I pronounce it gayj. So do most of the civil engineers I know. As for spelling, I'm likely to use gage for e.g. 22-gage steel deck, but I'm inclined to use gauge for fuel gauge. But that's just me. ~fantasai
Re: [whatwg] Comments and questions on Web Apps 1.0
Henri Sivonen wrote: 2.4.5. To set metadata with meta elements, authors must first specify a profile that defines metadata names, using the profile attribute. In my opinion, it would be useful to predefine the traditional names and Dublin Core. Predefining the traditional names would be a good idea. As for Dublin Core, I think they need to publish an XMDP profile. 2.9.3. In my opinion, marking up names of people and works in the same does not fit conventional presentational practice. On the other hand, using cite only for source citations causes different titles of works to be marked up differently. Using cite as a generic title of work could be marginally useful for styling. Is there any evidence that the way cite is currently defined is useful for any application? I still think cite fails the explaining to mother test. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005- August/004649.html Something else to think about: If cite is reserved only for source citations, what markup do we use for generic title of work? ~fantasai
Re: [whatwg] diffed versions (CVS)
Anne van Kesteren wrote: Would it be possible to use (public) CVS or Subversion for the drafts that are created so its easier to track changes in the document? Given that the document is quite large it makes it hard to track fixes and additions. As a reader/reviewer, I would have no idea what was done in the draft of 24 February as opposed to the one from 22 February 2006... Best thing would be if there was some list to which CVS diff-logs would be e-mailed or so. Would make it a lot easier to track changes. DreamHost does have cvs, so putting it in CVS is straightforward and quite easy. Making the diffs available would be harder: DreamHost only allows access over ssh, so anonymous access isn't possible. Bonsai could one option. Another would be to make CVS mail the diffs to an archived announcement list, and that's probably easier to set up quickly. I would appreciate CVS diffs, too. ~fantasai
Re: [whatwg] rel/rev for form ?
Henri Sivonen wrote: Lachlan Hunt wrote: He meant that the class names used should not be used to describe the presentation, but rather describe the semantics. It is, however, ok to use stylesheets to add styles based on the classes. eg. These are bad practice: span class=bold red-border p class=blue-text div class=big bold These are better: strong class=warning p class=summary h1 class=title (or simply h1) Of course, the UA does not care about semantic class names. In both cases, the UA only sees opaque strings that can be tested for equality with strings present in CSS selectors. The class names in the latter case may be semantic in the private universe of the author, but they do not communicate semantics to software developed by someone else without a prior agreement (possibly in the form of a third-party spec) on the meaning of the class names. While it's true that the UA does not understand the author's semantics, the second example is better coding because it separates content and style. To draw an analogy, if/else/while are all transformed to goto statement during compilation but writing if/else/while is nonetheless better C programming practice than writing gotos. ~fantasai
Re: [whatwg] rel/rev for form ?
Mike Dierken wrote: Dimitri Glazkov wrote: As for the tags attribute discussion, you guys just invented a class attribute. Well, that also was one suggestion, but 'class' is mostly for user interface rendering, rather than purely semantic meaning. But it may not be necessary or workable to have a 'purely semantic' attribute. Some web crawling system would likely be able to figure out the semantic equivalence if enough people used a small enough set of values for similar things. If you look at a lot of the current icroformats work, they are using classes on regular elements rather than 'rel' on links. http://www.microformats.org/blog/2005/10/19/more-than-styling/ http://microformats.org/wiki/hcalendar http://microformats.org/wiki/xoxo As Tantek likes to remind people: don't reinvent. ~fantasai
Re: [whatwg] [WA1] The a element could be empty
Matthew Raymond wrote: How many user agents support Javascript but not CSS1? Does Lynx or some other text-mode browser support Javascript? I'll have to look into that... ELinks is experimenting with SpiderMonkey. ~fantasai
[whatwg] WA1: base
# The href content attribute, if specified, must contain a URI (or IRI). Can the href attribute be empty? # User agents must use the value of the href attribute on the first base # element in the document as the document entity's base URI Current behavior is to use the nearest previous base element, be it prior sibling or cousin, and this is interoperably implemented in Mozilla and Opera. I think requiring that the first base apply to previous as well as following elements is a good idea for head, but you may need to investigate whether it is practical for base in body. # In a head element, before any elements that use relative URIs, and # only if there are no other base elements anywhere in the document. It would be simpler to just require base to be before any elements that use URIs period. It's easier to express, and there are no invalidation surprises if one changes an absolute URI to a relative one later on. ~fantasai
Re: [whatwg] [WA1] The a element could be empty
S. Mike Dierken wrote: An empty a element is semantically meaningless. An a element can be a target of a link - it is addressable via a URI. Does that count as meaningless? See http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 The destination anchor of a link may be an element within an HTML document. The destination anchor must be given an anchor name and any URI addressing this anchor must include the name as its fragment identifier. Destination anchors in HTML documents may be specified either by the A element (naming it with the name attribute), or by any other element (naming with the id attribute). The A element no longer has a name attribute in HTML 5; the 'id' attribute is a much better design, and is already well supported. http://www.whatwg.org/specs/web-apps/current-work/#the-a ~fantasai
Re: [whatwg] Image maps: should we drop a coords=?
Ian Hickson wrote: On Mon, 11 Apr 2005, Anne van Kesteren wrote: Yup, it is indeed nice; if image maps had been designed that way from the start it would make sense. But it's not _that_ much nicer than area, which we could define as allowing: object data=foo usemap=#foo map id=foo ul liarea coords=... href=...a href=../a ... ...which isn't much worse, and has the very important benefit of actually working in IE6. And the perhaps less important disadvantage that it's impossible for a machine to warn against the lack of alt text. With both area and a in HTML 4, the spec was able to require 'alt' attributes on area, because, given a coords=... to fill the mixed coords and fallback role, area was not intended to be used in conjunction with other fallback content. In what you're proposing, area also takes the role of a coords=... and therefore takes no 'alt' attribute. The end result is, there's no way to know if the author actually provided alt text or is just throwing area into a mix of random block content. *shrug* Just something to think about. Another thing to think about: afaict, the HTML 4 spec doesn't say whether or how the image map coordinate system scales when an image is stretched or shrunk via CSS. ~fantasai
[whatwg] WA1: footer, header content models and blockquote
The header and footer elements don't allow any sectioning elements, which includes blockquote. However, headers and footers sometimes include a short (but not inline) epigraph. How would you mark that up? ~fantasai
[whatwg] WA1: li processing
# If the attribute's value cannot be converted to a number, it is treated # as if the attribute was absent. The attribute has no default value. The attribute's value is treated as if the attribute was absent doesn't make a whole lot of sense to me. Did you mean a different 'it'? # The value attribute is processed by the parent ol element, if there is one. # If there is not, the attribute has no effect. The first sentence makes no sense. What does it mean for an element to process another element's attribute? I thought the UA processed the attributes. Is the second sentence meant to imply that when the parent is not ol the value DOM attribute reflects a missing 'value' attribute rather than whatever value the 'value' attribute actually has? If so, you should make it more explicit. If not, you should make /that/ explicit. # Each subsequent item in the list has the ordinal value given by its value # attribute, if it has one, or, if it doesn't, the ordinal value of the # previous item, plus one. The instructions in the ol section seem to omit any reference to the number conversion step described in the li section. Here's a suggestion: Replace # If the value attribute is present, user agents must convert the # value to a numeric type, truncating any fractional part, in order # to determine the attribute's value. If the attribute's value cannot # be converted to a number, it is treated as if the attribute was # absent. The attribute has no default value. # # The value attribute is processed by the parent ol element, if # there is one. If there is not, the attribute has no effect. with | If the value attribute is present, user agents must convert the | value to a numeric type, truncating any fractional part, in order | to determine the attribute's numerical value. If the attribute's | value cannot be converted to a number or the attribute is missing | (or the parent element is not an ol element)?, then the attribute | has no numerical value. and # Each subsequent item in the list has the ordinal value given by # its value attribute, if it has one, or, if it doesn't, the ordinal # value of the previous item, plus one. with | Each subsequent item in the list has the ordinal value given by | its value attribute's numerical value, if it has one, or, if it | doesn't, the ordinal value of the previous item plus one. (Either way, you should remove the comma before plus one.) ~fantasai
[whatwg] WA1: phrase elements content models
Why do code and samp allow structured inline content while kbd only allows strictly inline content? ~fantasai
[whatwg] Re: 1 webpage != 1 document
Bronwyn Boltwood wrote: Over on the pmwiki-users mailing list, we're having a discussion about the use of heading tags in the sidebar and document structure. You can read the thread at http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/16355. In short, the pmwiki-users list is trying to decide how do we keep headings used in the sidebar from wrecking the outline structure, and from outvoting the page's real name in search engine indexes. So far the consensus is to stop using heading in the sidebar, and fake them with some other element. I feel that this is a lesser evil, rather than a semantic improvement. As I see it, the root problem here is that the model of a what webpage is says that it's one document. But when did you last see a well-designed live webpage that contained *just* one document? If the W3C's site was constructed like that, we could only find other W3C pages if they were linked in the body text, because there would be no navigation links. Logically speaking, navigation is never the page content proper unless the page is a sitemap. Best practice in web design demands plenty of site-related content in every page, such as the masthead and navigation bar(s). There may also be document-related secondary content, like a sidebar for a magazine story. Evidently, real webpages contain more than just one document each. Does anyone else agree that the 1 webpage = 1 document idea is flawed? What if we had a way to mark content separate from the page's primary document, so that user agents can recognize these site-related and document-related chunks, and consider their heading structure separately from that of the primary document? You might want to take a look at what the WHATWG is doing with the Web Apps 1.0 drafts. The sectioning elements and heading structure in particular seem to address this problem. If you have suggestions for improvement, of course you are strongly encouraged to comment on the mailing list. http://www.whatwg.org/specs/web-apps/current-work/#sections http://www.whatwg.org/mailing-list ~fantasai
Re: [whatwg] Pattern Hint
Dean Edwards wrote: I know this has been suggested before, and was rejected, but I would quite like to see a pattern hint attribute added to Web Forms 2.0. With more complex input controls we should spare a thought for the poor user. http://www.whatwg.org/specs/web-forms/current-work/#the-pattern # Authors should include a description of the pattern in the title attribute. # User agents may use the contents of this attribute when informing the user # that the pattern is not matched, or at any other suitable time, such as in a # tooltip or read out by assistive technology when the control gains focus. ... # When a control has a pattern attribute, the title attribute, if used, must # describe the pattern. Additional information could also be included, so long # as it assists the user in entering the field. Otherwise, assistive technology # would be impaired. ? ~fantasai
[whatwg] WA1: xml:base
The xml:base attribute, unlike the xml:lang attribute, is not listed as a common attribute. It's also not listed as an element-specific attribute on any element. However, the prose says to use xml:base instead of base in XML documents. Could you specify more clearly where the xml:base attribute is allowed in xHTML 5? ~fantasai
[whatwg] WA1: hr
# 2.4.2. The hr element # # thematic separator. break. transition. hinge realignment. reconstruction, # refinement, remodeling, reversal, revision, revolution. Maybe an 'html # respite' or a 'hypertext rest'? . I like transition a lot. Hinge realignment seems a little too obscure. :) *flips through the H section of her English-Chinese dictionary, it being the only dictionary on hand around here* How about Hint tRansition? Other semi-useful H words include: hold, hook, horizon ... Hint seems the most appropriate, I think. ~fantasai
Re: [whatwg] WA1: meta attribute requirements
Ian Hickson wrote: On Tue, 19 Jul 2005, Christoph Päper wrote: h2Your todo list:/h2 ol /ol ...makes sense to me. Traditionally empty items have been filled with N/A, ./., -, (empty), none etc. or in this case maybe nothing to do. It's not like HTML was the first system to reuire items in lists or cells in tables. But that's a presentation issue. The list is semantically empty, it just happens to have Nothing to do rendered in its place. IMHO. FWIW, I agree with Ian here. ~fantasai
Re: [whatwg] WA1: meta attribute requirements
Ian Hickson wrote: On Tue, 19 Jul 2005, Olav Junker Kjær wrote: But the notion of conformance is still quite useful to authors and authoring tools. E.g. if a META-element without any attributes appears in a document, its clearly due to an oversight or a bug in some tool, so it would be useful to have a conformance checker or authoring tool flag this, even if a browsers will handle it somewhat gracefully (by ignoring it). Agreed. I agree that we need to make conformance checking useful, of course. I disagree that a blank meta/ is necessarily a problem. Maybe the author wanted to add some attributes dynamically later. Maybe he wants the DOM of all his pages to be equivalent and at that point in his pages there simply is no metadata to give. ... The difficulty is in walking the fine line between useful and over-constrained. For example, the fact that ol/ol is invalid in HTML4 is a real problem. Agreed with the last paragraph. One way of drawing the line might be, does dropping this requirement result in a semantically-meaningful representation? An empty list represents an empty list. But a meta without a 'name', or a link without a 'href': these, per spec, represent nothing. They do not even provide any structural semantics as div and span do; the document has the same semantics as if the element did not exist. ~fantasai
Re: [whatwg] WA1: rev attribute
Matthew Raymond wrote: Most common link types out there are used with 'rel', but some 'rev' values can also be useful. Here are some use cases: - rev=footnote for a link back from the footnote or endnote to the source anchor in the main text - rev=help for a link to the part of the site that the help text is about This is largely useless, as you are unlikely to start at a help/footnote document and go to the document for which the help document was written. The most common situation is that you clicked the help/footnote like from the parent document, and therefore the relationship is already established from the parent document. Or maybe I just scrolled to the bottom after reading the whole text straight through and want to jump to the context of the footnote I'm now reading. (The footnote and its context could be in the same document, too, y'know.) - rev=author on a personal site or resume for links to documents s/he has written Here, you're using |rev| to replace missing metadata in the target document. What happens when meta name=Author is defined in the target documents? Does |rev| override? What would a UA do with the information anyway? If there's a link, wouldn't there be text stating that the creator of the personal site created the document the link is to? I think you're missing the point here. 'rev' doesn't say anything more about the linked document than 'rel' does. It's just a way of expressing inverse relationships without having to pull out thesauri and latin prefixes and excessive hyphens. At least with |rel|, you could harvest hyperlinks and put them into a link toolbar. With |rev|, you're describing the relationship type of the current document. Therefore, I really don't see what user agents are supposed to do with |rev| and how they can create a useful interface that can exploit this attribute. The user agent doesn't need to do anything to make the markup useful: if you look at XFN, for example, UAs didn't support any of it, but authors still used the markup as hooks to for styling. Counterexample: | meta name=refuting content= | Intelligent Design; | http://hemadeyou.org | I don't think I need to say anything about how ridiculous a counter- suggestion that is. ~fantasai
[whatwg] WA1: rev attribute
The 'rev' attribute from prior versions of HTML is missing in WA1, and I think it deserves not to be left out. Most common link types out there are used with 'rel', but some 'rev' values can also be useful. Here are some use cases: - rev=footnote for a link back from the footnote or endnote to the source anchor in the main text - rev=help for a link to the part of the site that the help text is about - rev=author on a personal site or resume for links to documents s/he has written See also http://www.eastgate.com/HypertextNow/archives/Trigg.html for a direction link types could go in which 'rev' would be useful. Many of the link types suggested there would be easier to use with rev for the reverse link than with a separate keyword that means the inverse relationship. Example: rev=refutation to link to the article one is refuting ~fantasai
[whatwg] WA1: style element content model
# For styling languages that consist of pure text, user agents must use a
# concatenation of the contents of all the text nodes and CDATA nodes that are
# direct children of the style element (ignoring any other nodes such as
# comments or elements), in tree order.
This does not give the intended behavior in the following two HTML documents:
HTML document:
style type=text/css
.foo { content: foo/foo }
/style
HTML document:
style type=text/css
!--
.foo { color: blue }
--
/style
# For XML-based styling languages, user agents must use all the children
# nodes of the style element as the style.
Are HTML documents allowed to use such XML-based styling languages in
the style element as well?
~fantasai
[whatwg] WA1: base and href
In HTML 4, the 'href' attribute of the base element is #REQUIRED. Is there a reason why in HTML 5 it is not required? ~fantasai
