Re: [whatwg] Entity definitions in XHTML

[Leif Halvard Silli]

David Carlisle on Fri, 18 Jan 2013 00:03:12 +:
> To: Ian Hickson 
> On 17/01/2013 23:31, Ian Hickson wrote:
>> On Thu, 17 Jan 2013, David Carlisle wrote:

> that documents will be interpreted differently by an XHTML
> user agent and a standard XML toolchain.
 
 I do not understand what this means. Can you give an example?

Though not XML, the trouble Anolis had with putting out the correct 
glyph values for the ⟩ and ⟨ entities, was caused by a part 
of Anolis that interpreted those entities in the old, HTML5 
*in*compatible, way. This in turn resulted in the wrong character when 
the entities were converted to normal characters before being output to 
the HTML5 spec:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14430
This was a surprisingly long lasting bug. (And perhaps not fully solved 
yet …) It had probably existed since HTML5 included named entities in 
the spec. And, as the reporter of the bug, I was asked time and again 
and again about whether the bug had been fixed or not ...

In this case, Anolis outputted "polyglot" character references, since 
it converted the named reference to numeric references. (Please ignore 
HTML5's current shortcut: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20702) But since the bug 
actually was in Anolis’ list of named character references, this 
nevertheless caused a misrepresentation of the named entities.

>>> There is more to compatibility than compatibility between the
>>> browsers. For XHTML there needs to be compatibility between
>>> Browsers and XML tools (otherwise why use XML at all, I know you
>>> would rather people didn't but so long as the spec allows then to
>>> it should not mandate a situation that makes document corruption so
>>> likely).
>> 
>> There is no such mandate. The spec merely provides a catalogue of
>> public identifiers and their modern meaning. Nothing stops XML users
>>  from using any other identifier, in particular SYSTEM identifiers.
>> The spec discourages people from using DTDs in general, because of
>> precisely the kinds of issues that are being discussed here, but the
>>  XML spec allows it, and that's what controls this at the end of the
>>  day (especially in the case of software that isn't using the HTML
>> spec's catalogue).
>> 
> As I note above there are many existing systems using the Public
> identifiers of XHTML1 to refer to the XHTML1 DTD and using validating
> parsers. They can not simply switch in a catalog that makes their
> existing document collections invalid. So they can not make documents
> using the XHTML1 public identifier load a DTD other than XHTML1 DTD.

1) If the legacy XHTML DTDs are so risky, shouldn't the spec
   explicitly warned against using them in authoring of XHTML5
   documents?

2) David, have you considered the possibility of link this named
   entity magic to the legacy-compat variant of the HTML5 doctype?

   http://www.w3.org/TR/html5/syntax.html#doctype-legacy-string

   The advantage of doing so would be that nothing new needs to be
   introduced.
   The disadvantage (but perhaps advantage in Ian's eyes) ;-)
   would be the name of this doctype variant - "legacy".
-- 
leif halvard silli

Re: [whatwg] Entity definitions in XHTML

[David Carlisle]

On 17/01/2013 23:31, Ian Hickson wrote:

On Thu, 17 Jan 2013, David Carlisle wrote:


http://www.w3.org/2003/entities/2007doc/xhtmlpubid.html

But basically it solves the problem that the existing list leads to
a situation where data corruption and user confusion are both
inevitable as the only way to enable entities to be loaded into a
an xhtml agent is to reference a DTD that defines a different
incompatible set of entities.


This seems to be predicated on the assumption that the proposed new
identifier would identify a different DTD than the existing
identifiers.


The proposed identifier _by definition_ identifies the list that is in
the HTML spec. Not surprising since you extract the list from the same
place.


This is false. They would all identify the same DTD.



No, they don't. That is the trouble. Only the proposed one identifies
that list. The others are all pre-existing identifiers that identify
incompatible sets. It is fine in a browser context that you over-ride
that and load the HTML5 set in all cases but while you may control the
browser you can't control existing workflows that already use these
identifiers for the purposes for which they were defined, to identify
the XHTML and MathML2 DTD.

Browsers do not validate so can effectively
use an implicit catalog that switches in the data URL with the HTML
entities but since that contains no element definitions it would
completely break any XML tools that rely on validation.




The current list gives no way to specify the identifier of a
compatible set of entity definitions so makes it highly likely
 that documents will be interpreted differently by an XHTML
user agent and a standard XML toolchain.


I do not understand what this means. Can you give an example?


Yes.  If for example you use ⟬ then in an XHTML User Agent if
you specify one of the blessed DTD Identifiers the HTML entity set
will be loaded and the entity will expand to U+27EC (MATHEMATICAL
LEFT WHITE TORTOISE SHELL BRACKET) as intended however this
character was added at Unicode 5.1 years after MathML2 and XHTML 1
specifically to support this character so the definitions in the
legacy DTD are different.


There's only one DTD that XHTML UAs are supposed to have in their
catalogues at this point.


The only advantage of using XHTML as opposed to HTML syntax is that the
document is _not_ only parsed by XHTML specific UA but passes through
some general XML toolchain. The current list seems purpose designed to
break XML usage, it is also massively confusing for any human looking at
the file.

If you specify a DTD that defines the HTML entity set, no entities are
defined. If you specify a DTD which does not define them, they are all
defined. This is so obviously sub-optimal I honestly can't understand
how the bug can remain open for years after having been reported.





Currently you have to specify the XHTML 1 DTD or MathML 2 DTD. If
you use the former then in any (normally configured) xml toolchain
 you will get the XHTML 1 DTD the entity will not be defined and
the entire document is rejected with a fatal error. If you specify
the latter then the MathML2 DTD will be loaded and the entity will
 expand to the Asian punctuation character U+3018 (LEFT WHITE
TORTOISE SHELL BRACKET).


⟬ is defined to map to U+027EC in the DTD that the identifiers
 in the spec map to. If your tool chain is still using the legacy
DTDs, just update your tool chain.



Fundamentally, I'd rather be removing these magic strings than
adding more. If there's a compatibility need, then we should add
 it, but if the browsers don't already support the string, then
there's no compat need that I can see.


It _used_ to be possible to reference a usable dtd. The MathML2
spec worked in Firefox (every version up to 3) and Internet
explorer and any other browser of the period that I was aware of.
It was your first drafts of html(5) that introduced this bug by
restricting the doctype handling in a way that excluded any DTD
that defined the correct set of entities. Currently browsers have
converged on that erroneous list.


The list in the spec was based on what browsers implemented.


No. It is a subset of what mozilla did but bears no relation to what IE
did for example. But crucially mozilla also looked at the SYSTEM Id
(that is the URL) which allowed documents (eg the MathML2 spec) to use a
local dtd that defined an appropriate entity set as long as the local
dtd had "mathml" in its name. Special casing magic URL didn't make it
in to the spec (which is probably a good thing) but that combined with
the unfortunate list that doesn't include an identifier for the current
definitions completely broke existing XHTML use that was using the
entities and gives no reasonable way to fix it. (Other than not using
entities at all.)
(I've been advising people not to use entities in XHTML/MathML files
for 15 years but you more than anyone ought to know that users don't
always follow advice, and the system should accommodate use

Re: [whatwg] Entity definitions in XHTML

[Ian Hickson]

On Thu, 17 Jan 2013, David Carlisle wrote:
> 
> http://www.w3.org/2003/entities/2007doc/xhtmlpubid.html
> 
> But basically it solves the problem that the existing list leads to a 
> situation where data corruption and user confusion are both inevitable 
> as the only way to enable entities to be loaded into a an xhtml agent is 
> to reference a DTD that defines a different incompatible set of 
> entities.

This seems to be predicated on the assumption that the proposed new 
identifier would identify a different DTD than the existing identifiers.

This is false. They would all identify the same DTD.


> > > The current list gives no way to specify the identifier of a 
> > > compatible set of entity definitions so makes it highly likely that 
> > > documents will be interpreted differently by an XHTML user agent and 
> > > a standard XML toolchain.
> > 
> > I do not understand what this means. Can you give an example?
> 
> Yes.  If for example you use ⟬ then in an XHTML User Agent if you 
> specify one of the blessed DTD Identifiers the HTML entity set will be 
> loaded and the entity will expand to U+27EC (MATHEMATICAL LEFT WHITE 
> TORTOISE SHELL BRACKET) as intended however this character was added at 
> Unicode 5.1 years after MathML2 and XHTML 1 specifically to support this 
> character so the definitions in the legacy DTD are different.

There's only one DTD that XHTML UAs are supposed to have in their 
catalogues at this point.


> Currently you have to specify the XHTML 1 DTD or MathML 2 DTD. If you 
> use the former then in any (normally configured) xml toolchain you will 
> get the XHTML 1 DTD the entity will not be defined and the entire 
> document is rejected with a fatal error. If you specify the latter then 
> the MathML2 DTD will be loaded and the entity will expand to the Asian 
> punctuation character U+3018 (LEFT WHITE TORTOISE SHELL BRACKET).

⟬ is defined to map to U+027EC in the DTD that the identifiers in 
the spec map to. If your tool chain is still using the legacy DTDs, just 
update your tool chain.


> > Fundamentally, I'd rather be removing these magic strings than adding 
> > more. If there's a compatibility need, then we should add it, but if 
> > the browsers don't already support the string, then there's no compat 
> > need that I can see.
> 
> It _used_ to be possible to reference a usable dtd. The MathML2 spec 
> worked in Firefox (every version up to 3) and Internet explorer and any 
> other browser of the period that I was aware of. It was your first 
> drafts of html(5) that introduced this bug by restricting the doctype 
> handling in a way that excluded any DTD that defined the correct set of 
> entities. Currently browsers have converged on that erroneous list.

The list in the spec was based on what browsers implemented.


> There is something very broken with the process if it is impossible to 
> fix bugs in the spec if some implementations implement the broken spec 
> text.

Welcome to the Web. Lots of things are broken due to this kind of thing... 
(pushState being my favourite example...)


> There is more to compatibility than compatibility between the browsers. 
> For XHTML there needs to be compatibility between Browsers and XML tools 
> (otherwise why use XML at all, I know you would rather people didn't but 
> so long as the spec allows then to it should not mandate a situation 
> that makes document corruption so likely).

There is no such mandate. The spec merely provides a catalogue of public 
identifiers and their modern meaning. Nothing stops XML users from using 
any other identifier, in particular SYSTEM identifiers. The spec 
discourages people from using DTDs in general, because of precisely the 
kinds of issues that are being discussed here, but the XML spec allows it, 
and that's what controls this at the end of the day (especially in the 
case of software that isn't using the HTML spec's catalogue).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Adding winding rules to Canvas

[Rik Cabanier]

All,

so after talking to Dirk, maybe it's better to rename the classes so Path
is the one that has the geometry and StyledPath contains the region.
Prototype IDL:

[Constructor,

Constructor(path), // creates a copy

Constructor(DOMString)] //takes SVG path syntax

interface Path {
};
Path implements CanvasPathMethods;

[Constructor,
Constructor(Path, CanvasWindingRule = "nonzero"), // creates a copy of path
Constructor(DomString text, CanvasDrawingSTyles, SVGMatrix?, unrestricted
double , unrestricted double , optional unrestricted double)]

interface StyledPath {

StyledPath Transform(matrix); // returns a transformed path
StyledPath Stroke(CanvasDrawingStyles); // returns a stroked path
StyledPath Add(StyledPath); // returns a path that is the union of the 2
paths

boolean isPointInPath(unrestricted double x, unrestricted double y);

};

interface CanvasRenderingContext2D {


void Fill(StyledPath);

}

dictionary HitRegionOptions {

StyledPath? path = null;


}



Any comments?

On Tue, Jan 15, 2013 at 1:49 PM, Rik Cabanier  wrote:

> Hi Simon,
>
> I completely agree with you.
> As specified today, hit regions don't have support for winding. In fact,
> it is even worse: if you have a set of drawing commands, you can't get
> their region.
> The reason for this is that the path object (as currently defined) simply
> accumulates path segments. This will wreak havoc with shapes that touch or
> that have strokes.
>
> I have stated this a couple of times already on whatwg...
> What I would like to see is more like this:
>
> class PathSink implements CanvasPathMethods {
>   PathSink();
>   PathSink(DOMString); //takes SVG path syntax
> }
>
> class Path {
>   Path();
>   Path(PathSink, CanvasWindingRule = "nonzero");
>   Path(DomString text, CanvasDrawingSTyles...); // to get text outline
>
>   Path Transform(matrix Transformation);
>   Path Stroke(...);
>
>   Path Add(Path); // <
> }
>
>
> The 'Add' method would not simply aggregate path segments. Instead, the
> area of resulting path will be a union.
>
> So, for example, if you want to create a region with a stroke rectangle:
>
> var h = new PathSink();
> h.rect(100, 100, 200, 200);
> var P = new Path(h);
> P = P.Add(P.Stroke({'lineWidth': 10}));
>
>
>
> On Tue, Jan 15, 2013 at 1:23 PM, Simon Sarris wrote:
>
>> Before we comment on your proposal I have some notes I'd like to share
>> because the current *fillRule *rules in the specification seem
>> incomplete or at least ill-defined.
>>
>> The new hit regions use a *Path* in the *HitRegionOptions* (the argument
>> to *addHitRegion*) in order to function, but its not clear what fill
>> rule these *Path* objects are using for hit-testing. Even-odd and
>> winding fill rules create different holes in a path, so it matters a good
>> deal for hit testing.
>>
>> There seem to be three possibilities as implemented:
>>
>>1. HitRegions only ever use winding paths. This seems like a bad idea.
>>2. Whichever *fillRule* is defined when *context.addHitRegion* is
>>called determines the *fillRule *for that hit region's *Path *permanently.
>>This seems acceptable but confusing and should be clarified if it is
>>currently the case.
>>3. The fillRule of a hit region changes dynamically as *
>>context.fillRule* changes. This would be a nightmare.
>>
>>
>> I hope it is #2, but the specification makes no mention of this.
>>
>> Actually, I'd prefer that either *HitRegionOptions *or the *Path *object
>> would need to have a *fillRule *attribute.
>>
>> If the specification does adopt something similar to Cabanier's
>> suggestions then that would need to be done anyway.
>>
>> In short, if *isPointInPath *is changed to specify *fillRule*, *
>> HitRegionOptions* (the argument to *addHitRegion*) or the *Path* given
>> in the options needs to change too.
>>
>>
>> Simon Sarris
>>
>>
>> On Tue, Jan 15, 2013 at 3:42 PM, Rik Cabanier  wrote:
>>
>>> All,
>>>
>>> there was a recent discussion on adding winding rules to canvas. As you
>>> may know until now, canvas only supported even-odd winding.
>>> Maybe graphics libraries and SVG also support non-zero winding.[1][2]
>>>
>>> Mozilla exposes this currently with 'mozFillRule'. Making this part of
>>> the graphics state has several drawbacks.
>>> The biggest is that fill/clip will now have to check the state every
>>> time, or set/reset it. Winding is also part of path geometry.
>>>
>>> I have the following proposal:
>>>
>>> enum CanvasWindingRule { "nonzero", "evenodd" };
>>> void fill(optional CanvasWindingRule w = "nonzero");
>>> void clip(optional CanvasWindingRule w = "nonzero");
>>> boolean isPointInPath(unrestricted double x, unrestricted double y,
>>> optional CanvasWindingRule w = "nonzero");
>>>
>>>
>>> proposed patches for this API can be found here:
>>> https://bugs.webkit.org/show_bug.cgi?id=105508
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=827053
>>>
>>> What do people think?
>>>
>>> 1: http://www.w3.org/TR/SVG/painting.html#FillRuleP

[whatwg] Magic alignment issues

[Ian Hickson]

On Fri, 7 Dec 2012, Matt Falkenhagen wrote:
>
> How are cycles with magically aligned elements resolved?
> 
> For example, if a and b are dialogs and you do:
> 
> a.show(b);
> b.show(a);
>
> I think an anchoring cycle can also occur if an element |a| is anchored 
> to a descendent of an element anchored to |a|.

On Mon, 10 Dec 2012, Tab Atkins Jr. wrote:
> 
> This is a closely-related problem to what I ran into when writing up my 
> proposal for Positioned Layout . The 
> only correct answer is to do cycle-detection, and break the cycle at 
> some predictable location.  In Positioned Layout I used document order 
> to figure out where to break the cycle, but here you have a nice 
> temporal ordering already available - if a show() call would produce a 
> cycle, it should instead act as if no anchor was provided.

The temporal order isn't that useful. Consider:

 
   a.show(b);
   b.show(c);
   a.appendChild(c);

I think we're forced to rely on the tree order here too. It's unfortunate, 
but I really can't see a better solution.


On Tue, 11 Dec 2012, Matt Falkenhagen wrote:
>
> The spec seems unclear on whether a magically aligned element[1] should 
> follow its anchor when its anchor moves, e.g., by dynamic style changes 
> or something like CSS animations.

It should. I've tried to make this explicit, but it was supposed to be 
already required by the use of the word "while" and other such phraseology 
in the requirements.


> Relatedly, it's not clear what happens if anchor is display: none or is 
> not in the document when show() is called, but later has a rendered box 
> and is in the document. And the reverse: if it is in the document when 
> show() is called and later is removed.

The requirements apply continually while they match, so while one is 
'display:none' (or not in the doc, or whatever) the 'position' property on 
the anchored element will compute normally, but once the conditions are 
met, it will compute to 'absolute-anchored', and then the requirements on 
'absolute-anchored' apply.


On Tue, 11 Dec 2012, Tab Atkins Jr. wrote:
>
> The spec defines this - the magical alignment only happens while A and B 
> have rendered boxes.  When the conditions don't apply, it's not 
> magically aligned.  (The spec's recommendation for CSS is somewhat badly 
> designed for this - assume that it merely forces A to 
> "position:absolute", and while B doesn't have a box, A isn't anchored 
> and is interpreted as a normal abspos box.)

How should I change the spec to not be badly designed here?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Entity definitions in XHTML

[David Carlisle]

On 17/01/2013 18:58, Ian Hickson wrote:

On Thu, 17 Jan 2013, David Carlisle wrote:


By adding

"-//W3C//ENTITIES HTML MathML Set//EN//XML"

To the list in

13.2 Parsing XHTML documents

Of Identifiers that are recognised when parsing XHTML syntax documents.


What problem does this solve?


We tried to spell out various problems in the referenced document at

http://www.w3.org/2003/entities/2007doc/xhtmlpubid.html

But basically it solves the problem that the existing list leads to a 
situation where data corruption and user confusion are both inevitable 
as the only way to enable entities to be loaded into a an xhtml agent is 
to reference a DTD that defines a different incompatible set of entities.







The current list gives no way to specify the identifier of a compatible
set of entity definitions so makes it highly likely that documents will
be interpreted differently by an XHTML user agent and a standard XML
toolchain.


I do not understand what this means. Can you give an example?


Yes.  If for example you use ⟬ then in an XHTML User Agent if you 
specify one of the blessed DTD Identifiers the HTML entity set will be 
loaded and the entity will expand to U+27EC (MATHEMATICAL LEFT WHITE 
TORTOISE SHELL BRACKET) as intended however this character was added at 
Unicode 5.1 years after MathML2 and XHTML 1 specifically to support this 
character so the definitions in the legacy DTD  are different.


Currently you have to specify the XHTML 1 DTD or MathML 2 DTD. If you 
use the former then in any (normally configured) xml toolchain you will 
get the XHTML 1 DTD the entity will not be defined and the entire 
document is rejected with a fatal error. If you specify the latter then 
the MathML2 DTD will be loaded and the entity will expand to the Asian 
punctuation character U+3018 (LEFT WHITE TORTOISE SHELL BRACKET).


The sole purpose of the requested chain is to allow the document to 
reference a set of entity definitions that matches the definitions that 
will be used in the browser.





Fundamentally, I'd rather be removing these magic strings than adding
more. If there's a compatibility need, then we should add it, but if the
browsers don't already support the string, then there's no compat need
that I can see.


It _used_ to be possible to reference a usable dtd. The MathML2 spec 
worked in Firefox (every version up to 3) and Internet explorer and any 
other browser of the period that I was aware of. It was your first 
drafts of html(5) that introduced this bug by restricting the doctype 
handling in a way that excluded any DTD that defined the correct set of 
entities. Currently browsers have converged on that erroneous list.


There is something very broken with the process if it is impossible to 
fix bugs in the spec if some implementations implement the broken spec text.



There is more to compatibility than compatibility between the browsers.
For XHTML there needs to be compatibility between Browsers and XML tools 
(otherwise why use XML at all, I know you would rather people didn't but 
so long as the spec allows then to it should not mandate a situation 
that makes document corruption so likely).


David

Re: [whatwg] Make the files attribute of the input element writable

[Ian Hickson]

On Fri, 7 Dec 2012, Victor Costan wrote:
> On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson  wrote:
> > On Wed, 5 Dec 2012, Victor Costan wrote:
> >>
> >> There was a thread on this mailing list discussing making it possible 
> >> to set the file data behind an  element. 
> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140
> >>
> >> The thread seems to have died down due to insufficient applications 
> >> for the proposal.
> >
> > Actually the reason this thread hasn't gone anywhere is that there 
> > seems to only be implementer interest from Chrome.
> >
> > See: 
> > http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest
> 
> Thank you very much for explaining!
> 
> I can file a bug against Firefox, and argue for it. I think I would have 
> an easier time making an argument if I knew how the API should look 
> like. Can you please give me a hint as to which variant you'd be more 
> likely to agree with?

Whatever browsers are willing to implement, basically.


> >> 1) This would make it possible to write JavaScript libraries that 
> >> seamlessly scan the current page for  and add 
> >> integration with Dropbox / Google Drive / Sky Drive etc. I claim that 
> >> changing the  value is the easiest and most robust method of 
> >> achieving this without requiring changes to the main application 
> >> code. Asides from providing an easy path for developers to integrate 
> >> online storage services into their apps, this change would make it 
> >> easy to write bookmarklets / browser extensions that add this 
> >> functionality to any Web application.
> >
> > It seems like this use case would be better handled by having the 
> > sites offer an API to the browser, similar to Web Intents, for picking 
> > a file. That way you wouldn't need to update each site -- every site 
> > would support all the drive systems you use.
> 
> Yes, but that approach would require deeper application changes. I think 
> that adding a couple of 

Re: [whatwg] Confusing text relating to

[Ian Hickson]

On Thu, 17 Jan 2013, Jonathan Watt wrote:
>
> The text on  at:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29
> 
> says:
> 
>   The step scale factor is 1. The default step is 1 (allowing only
>   integers, unless the min attribute has a non-integer value).
> 
> I found the words "allowing only integers" to be confusing. I initially 
> read it to mean that "step" is only allowed integer values unless the 
> "min" attribute is a number with a fractional part. Talking it over with 
> dbaron we believe it is probably just a parenthetical observation that 
> if the "min" attribute's value is an integer and the default value of 1 
> for "step" is being used, then the input's value can only have integer 
> values. (This is unclear because the input's value isn't otherwise 
> mentioned in the sentence.)

Clarified.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Implementation issue: step mismatch handling for

[Ian Hickson]

On Thu, 17 Jan 2013, Jonathan Watt wrote:
>
> I'm working on implementing  for Gecko and have 
> encountered what I believe to be an issue in the spec.
> 
> Step 1 of the algorithm to find the "step base":
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero
> 
> says "If the element has a min content attribute...to the value of the 
> min content attribute...". Should this not talk about "minimum" rather 
> than "min content attribute"? It would otherwise seem to give bad 
> results in the case of , which has a default minimum 
> of zero (a default minimum makes sense in the case of type=range, since 
> an unbounded slider would be impossible for a user to interact with). 
> Consider for example:
> 
>   
> 
> As it stands, the current spec text says that the "step base" is -1 
> (from the 'value' content attribute), the 'minimum' is zero (from the 
> default minimum), the 'maximum' is 1, and the step is 3.

Right.


> As a result, an implementation would seem to be directed to enter an 
> infinite loop applying the paragraphs beginning with "When the element 
> is suffering from an underflow..." and "When the element is suffering 
> from a step mismatch..." in:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29

First the element is suffering from an underflow but not a step mismatch, 
so the user agent must set the element's value to a valid floating-point 
number that represents the minimum (0).

Now the element is suffering from a step mismatch but not an underflow, so 
the user agent must round the element's value to the nearest number for 
which the element would not suffer from a step mismatch, and which is 
greater than or equal to the minimum, and, if the maximum is not less than 
the minimum, which is less than or equal to the maximum.

There's no such value. This isn't an infinite loop, but it is indeed an 
error. Fixed, by adding "if there is a number that matches these 
constraints", which means that the value now ends up at 0 and remains 
suffering from a step mismatch.


> If the step base considered the 'minimum' instead of the 'min' content 
> attribute, then the step base would be zero, and thus the value would 
> settle at zero.

Right, but that would be highly unlikely to make sense, because it would 
mean the value the author set was an invalid value. You shouldn't be 
forced to specify the minimum if you're already specifying a step and a 
value and the default minimum of zero is adequate.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Confusing text relating to

[Jonathan Watt]

The text on  at:

http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29

says:

  The step scale factor is 1. The default step is 1 (allowing only
  integers, unless the min attribute has a non-integer value).

I found the words "allowing only integers" to be confusing. I initially read it 
to mean that "step" is only allowed integer values unless the "min" attribute is 
a number with a fractional part. Talking it over with dbaron we believe it is 
probably just a parenthetical observation that if the "min" attribute's value is 
an integer and the default value of 1 for "step" is being used, then the input's 
value can only have integer values. (This is unclear because the input's value 
isn't otherwise mentioned in the sentence.)


Jonathan

Re: [whatwg] Implementation issue: step mismatch handling for

[Jonathan Watt]

On 17/01/2013 19:29, Jonathan Watt wrote:

I'm working on implementing  for Gecko and have encountered
what I believe to be an issue in the spec.

Step 1 of the algorithm to find the "step base":

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero

says "If the element has a min content attribute...to the value of the min
content attribute...". Should this not talk about "minimum" rather than "min
content attribute"? It would otherwise seem to give bad results in the case of
, which has a default minimum of zero (a default minimum makes
sense in the case of type=range, since an unbounded slider would be impossible
for a user to interact with). Consider for example:



As it stands, the current spec text says that the "step base" is -1 (from the
'value' content attribute), the 'minimum' is zero (from the default minimum),
the 'maximum' is 1, and the step is 3. As a result, an implementation would seem
to be directed to enter an infinite loop


An alternative reading of the paragraph beginning "When the element is suffering 
from a step mismatch" would be that there is no value that can satisfy the 
constraints of being both greater than or equal to the minimum, less than or 
equal to the maximum, and not suffer from a step mismatch. In which case the 
spec doesn't seem to define the behavior. Changing the step base text to refer 
to "minimum" instead of "'min' content attribute" would also fix things from 
that perspective.


Jonathan


applying the paragraphs beginning with
"When the element is suffering from an underflow..." and "When the element is
suffering from a step mismatch..." in:

http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29

If the step base considered the 'minimum' instead of the 'min' content
attribute, then the step base would be zero, and thus the value would settle at
zero.

Jonathan

[whatwg] Implementation issue: step mismatch handling for

[Jonathan Watt]

I'm working on implementing  for Gecko and have encountered 
what I believe to be an issue in the spec.


Step 1 of the algorithm to find the "step base":

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero

says "If the element has a min content attribute...to the value of the min 
content attribute...". Should this not talk about "minimum" rather than "min 
content attribute"? It would otherwise seem to give bad results in the case of 
, which has a default minimum of zero (a default minimum makes 
sense in the case of type=range, since an unbounded slider would be impossible 
for a user to interact with). Consider for example:


  

As it stands, the current spec text says that the "step base" is -1 (from the 
'value' content attribute), the 'minimum' is zero (from the default minimum), 
the 'maximum' is 1, and the step is 3. As a result, an implementation would seem 
to be directed to enter an infinite loop applying the paragraphs beginning with 
"When the element is suffering from an underflow..." and "When the element is 
suffering from a step mismatch..." in:


http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29

If the step base considered the 'minimum' instead of the 'min' content 
attribute, then the step base would be zero, and thus the value would settle at 
zero.


Jonathan

Re: [whatwg] Feedback on a variety of elements

[Ian Hickson]

On Thu, 17 Jan 2013, Steve Faulkner wrote:
> hixie wrote:
> > > On Sun, 10 Jun 2012, Steve Faulkner wrote:
> > > >> >
> > > >> > You don't clearly differentiate between roles, properties and 
> > > >> > states, ther are quite a few states and properties NOT provided 
> > > >> > in HTML5 that may have use cases for adding to an input 
> > > >> > element, for example aria-hapopup, aria-labelledby, 
> > > >> > aria-decirbedby, aria-controls etc
> > > >
> > > > Could you give an example of any of these in valid use?
> > >
> > > the following input (gmail search box) uses aria-haspopup=true
> > >
> > >  > > class="gbqfif" id="gbqfq" *aria-haspopup="true"* style="border: 
> > > medium none; padding: 0px; margin: 0px; height: auto; width: 100%; 
> > > background: 
> > > url("data:image/gif;base64,R0lGODlhAQABAID/AMDAwCH5BAEALAABAAEAAAICRAEAOw%3D%3D")
> > >  
> > > repeat scroll 0% 0% transparent; position: absolute; z-index: 6; 
> > > left: 0px;" dir="ltr" spellcheck="false">
> >
> > Interesting. Can you elaborate on how this actually works? That is, 
> > aria-haspopup tells the AT that activating the element shows a popup, 
> > but what does activating the element mean? How does the AT expose this 
> > to the user? How does the user know what to do with this?
> 
> aria-haspop maps to haspopup state in acc APIs
>
> Typically the user gets notified that there is a sub menu and may 
> (depending on verbosity preferences) get told how to interact with it.

How does the user agent know how the user is to interact with it?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Entity definitions in XHTML

[Ian Hickson]

On Thu, 17 Jan 2013, David Carlisle wrote:
> 
> By adding
> 
> "-//W3C//ENTITIES HTML MathML Set//EN//XML"
> 
> To the list in
> 
> 13.2 Parsing XHTML documents
> 
> Of Identifiers that are recognised when parsing XHTML syntax documents.

What problem does this solve?


> The current list gives no way to specify the identifier of a compatible 
> set of entity definitions so makes it highly likely that documents will 
> be interpreted differently by an XHTML user agent and a standard XML 
> toolchain.

I do not understand what this means. Can you give an example?


Fundamentally, I'd rather be removing these magic strings than adding 
more. If there's a compatibility need, then we should add it, but if the 
browsers don't already support the string, then there's no compat need 
that I can see.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Feedback on a variety of elements

[Steve Faulkner]

hixie wrote:

> > On Sun, 10 Jun 2012, Steve Faulkner wrote:
> > >> >
> > >> > You don't clearly differentiate between roles, properties and
> > >> > states, ther are quite a few states and properties NOT provided in
> > >> > HTML5 that may have use cases for adding to an input element, for
> > >> > example aria-hapopup, aria-labelledby, aria-decirbedby,
> > >> > aria-controls etc
> > >
> > > Could you give an example of any of these in valid use?
> >
> > the following input (gmail search box) uses aria-haspopup=true
> >
> >  > id="gbqfq" *aria-haspopup="true"* style="border: medium none; padding: 0px;
> > margin: 0px; height: auto; width: 100%; background:
> > url("data:image/gif;base64,R0lGODlhAQABAID/AMDAwCH5BAEALAABAAEAAAICRAEAOw%3D%3D")
> > repeat scroll 0% 0% transparent; position: absolute; z-index: 6; left:
> > 0px;" dir="ltr" spellcheck="false">
>
> Interesting. Can you elaborate on how this actually works? That is,
> aria-haspopup tells the AT that activating the element shows a popup, but
> what does activating the element mean? How does the AT expose this to the
> user? How does the user know what to do with this?


aria-haspop maps to haspopup state in acc APIs

Typically the user gets notified that there is a sub menu and may
(depending on verbosity preferences) get told how to interact with it.

--
with regards

SteveF

[whatwg] Entity definitions in XHTML

[David Carlisle]

This is a further attempt to resolve the bug report (currently with
status  wontfix) regarding XHTML entity definitions.

(whatwg)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17798

(w3c)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13409

By adding

"-//W3C//ENTITIES HTML MathML Set//EN//XML"

To the list in

13.2 Parsing XHTML documents

Of Identifiers that are recognised when parsing XHTML syntax documents.

The current list gives no way to specify the identifier of a
compatible set of entity definitions so makes it highly likely that
documents will be interpreted differently by an XHTML user agent and a
standard XML toolchain. This is bad considering that being able to use
xml tools on the document is about the only reason for wanting to
serve the document as xhtml rather than text/html.

Further rationale is given in a message on the w3c list here:

http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0021.html

But I wanted to flag it here as well as this list presumably reaches a
different audience.

In particular a question for implementers, would adding

"-//W3C//ENTITIES HTML MathML Set//EN//XML"

to the list of recognised doctype PUBLIC identifiers be
impossibly hard, trivially easy, or inconvenient but you'd do it if
the spec changed?



Ian said in the original bug (comment 11)

> I'm happy to add new DTDs to the list; all you have to do is show that
> the URL you want to add already works in the majority of deployed
> browsers. To do that, please simply provide trivial test cases that
> use the DTD you want to have supported. It's not clear to me from this
> bug so far what exactly it is you want changed in the spec.

However "already works" is a rather impossible criterion for fixing
this problem. There were previously doctype declarations that worked
(as witnessed by the XHTML version of the MathML2 spec) but current
browsers have converged on the list as specified in HTML so
implementations have followed the spec which means it is now not
possible to use entities in XHTML if you specify a DTD that defines
them, but is if you specify a DTD that does not.  Adding one extra
recognised PUBLIC identifier gives a way that documents may be
produced that work on pre-html5 browsers and browsers updated to
recognise the additional string and also work with standard xml tools.


http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#parsing-xhtml-documents



David


The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 

[whatwg] DOMError not constructable

[Alex Russell]

It appears that WebIDL-ese has afflicted DOMError and DOMException:
http://dom.spec.whatwg.org/#interface-domerror

These should be constructable, with a single "name" DOMStrong parameter or
an argument bag which allows setting of the name property.

Regards