Re: [whatwg] for currency input

[Nils Dagsson Moskopp]

Michael Gratton  writes:

> Hi,
>
> As the spec currently stands, use of  is unsuitable 
> for currency and other input that require a minimum number of decimal 
> points displayed. When displaying decimal currency values, the typical 
> convention is that a precision of two decimal points is used, 
> regardless of numeric value. That is, one dollar is displayed as 
> "1.00", not "1". However the latter is the result when using  type=number> in implementations that follow the spec, such as Chrome 
> and Firefox.
>
> Section "4.10.5.1.9 Number state (type=number)" currently states: "If 
> the user agent provides a user interface for selecting a number, then 
> the value must be set to the best representation of the number 
> representing the user's selection as a floating-point number" - 
> effectively by calling JavaScript's ToString on the number. This gives 
> rise to the undesirable representation above.
>
> Since both the spec and existing implementations use the step attribute 
> to effectively specify the maximum number of decimal points for the 
> representation of the number, it also seems reasonable for the step 
> attribute to also define the minimum. This can perhaps be acheived by 
> changing the definition of the "best representation of the number n as 
> a floating-point number" to use the JavaScript Number.ToPrecision 
> function, and obtaining the precision from the step attribute, rather 
> than using ToString.
>
> This will work for integral currencies by specifying a step of 1, as 
> well as decimal currencies that that use a single decimal point, by 
> specifying a step of "0.1".
>
> Thoughts?

I think that float is simply the wrong data type for fractional amounts
of currency. Let me tell you an abrasive programmer joke regarding that:

bool gender;
int phone_number;
float money_amount;


Cheers,
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] New approach to activities/intents

[Nils Dagsson Moskopp]

Roger Hågensen  writes:

> On 2014-11-10 10:35, Anne van Kesteren wrote:
>> On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen  wrote:
>>> A worthy goal would be to help developers de-clutter websites from all those
>>> share icons we see today, so if this could be steered towards that it would
>>> be great.
>> That is what the proposal is doing. The share button would be part of
>> the browser UI. Perhaps you misunderstood it?
>>
>> (However, it is unclear whether all domains are interested in such a 
>> migration.)
>>
>>
>
> I must have miss-understood, I saw window.close() mentioned and I 
> thought this was a javascript API suggestion for yet another way to 
> sharing things.
>
> I looked a bit close now and wonder if this is related in any way to 
> https://wiki.mozilla.org/Mobile/Archive/Sharing ?
>
> Do you plan to go for a OpenShare route (modeled after OpenSearch) or 
> something simpler like I mentioned earlier?
>
> If all a web author need to do is slap a rel="share" on a  tag or a 
>  tag in the head and then have it automatically appear/listed in a 
> browser Share UI for that page then that would be ideal in my
> oppinion.

For the record: Every browser has a “Share UI” already. It is called the
address bar. You do not need to do anything to opt into it besides using
URLs. Granted, lots of hipster developers bend around backwards to avoid
using URLs, but to me it seems you already have a usable mechanism.

May I ask if the “share” idea is conflating mechanism and policy?

> Something like a OpenShare could build further on this hopefully, but 
> for wide adoption the simpler the better.
> Also OpenSearch is for searching an entire site or parts of it, wile a 
> OpenShare would be just for one page or link so that would be overkill 
> and it would cause another HTTP request to occur which is a waste IMO.
>
> I'm also curious if any browsers actually do something if multiple 
> rel="bookmark" exist in a page (head and body), are they taken into 
> account in the Bookmark UI at all? I certainly can not recall eve seeing 
> this happen.
>
> A quick test in Chrome, Firefox, Opera, IE here with the following in 
> :
> http://example.com/test3"; rel="bookmark" title="Test 3">
> http://example.com/test4"; rel="bookmark" title="Test 4">
>
> And the following in ;
> http://example.com/test!"; rel="bookmark" title="Test 1">Click 
> Here1
> http://example.com/test2"; rel="bookmark" title="Test 2">Click 
> Here2
> http://example.com/test0"; title="Test 0">Click Here0
>
> The result is the same, if I use the Browser UI bookmark then the head 
> links are ignored, and if I right link the body a link then I'm not 
> given a bookmark choice at all, just copy the url or save it.
>
> If bookmark is so ignored perhaps it would be best to take bookmark (and 
> to some extent canonical) and roll that into a rel="share" standard 
> which is defined/tied to this activities/intent proposal?
>
> Note! Firefox allows right clicking any URL and choosing to Bookmark it, 
> and IE does the same but it called Favorites there instead, in either 
> case I assume that rel=bookmark is ignored and the title is also ignored 
> as the "test0" link which does not specify rel bookmark is treated 
> identically to them. Opera and Chrome does not seem to allow right 
> clicking a URL and bookmark it. As I do not have Safari I have no idea 
> what it does in these cases.
>
> -- 
> Roger "Rescator" Hågensen.
> Freelancer - http://www.EmSai.net/
>

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Clarification for window.opener.location.href

[Boris Zbarsky]

On 1/7/15 3:55 PM, Nicholas C. Zakas wrote:

Yeah, that works well if you're dealing with bleeding-edge browsers
only. Not so much elsewhere.


Non-bleeding-edge browsers would also have the existing 
window.opener.location.href behavior, right?  As in, asking for a spec 
change to the way the href setter works to work around lack of support 
for another part of the spec (rel=noreferrer) is only useful if you 
assume browsers would implement the change to the setter faster than 
they'll implement support for rel=noreferrer.  I personally don' find 
that very likely, since rel=noreferrer is already shipping in at least 
Chrome and Firefox and doesn't require nearly the amount of web compat 
testing that the other change would.


Or is the above just a general complaint, as opposed to a reason to 
change the behavior of the href setter?


-Boris

Re: [whatwg] Clarification for window.opener.location.href

[Nicholas C. Zakas]

Yeah, that works well if you're dealing with bleeding-edge browsers 
only. Not so much elsewhere. :-/ Unfortunately, this isn't a case where 
progressive enhancement is a suitable approach to dealing with such a 
security issue.


-N

On 1/6/2015 12:16 PM, Boris Zbarsky wrote:

On 1/6/15 3:10 PM, Nicholas C. Zakas wrote:

Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well.


Not if you use rel="nofollow", per spec.  Browser support there is 
still spotty but improving.


Of course that affects more than just window.opener (e.g. affects 
whether a referrer is sent)


-Boris


--
___
Nicholas C. Zakas
http://www.nczonline.net

Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos

[Florian Rivoal]

> On 07 Jan 2015, at 00:29, Ian Hickson  wrote:
> 
> On Mon, 10 Nov 2014, Florian Rivoal wrote:
>> 
>> :hover matches on the labeled control of a label element currently 
>> matching :hover.
>> 
>> Similarly, :active interoperably matches on the labeled control of a 
>> label element currently matching :active (and 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27247 is about reflecting 
>> that in the spec)
>> 
>> In addition, IE (tested IE10 and IE11) makes it work the other 
>> direction, making :hover (resp. :active) match on the label of a labeled 
>> control currently matching :hover (resp. :active).
>> 
>> Given that this behaviour sounds reasonable
> 
> Why does it sound reasonable? I'd argue it's the other way around. Having 
> :hover match an element that isn't being hovered is weird.

It seems no less reasonable than in the other direction, which we already have. 
If state is going to propagate, propagating both ways is an easier to 
understand model.

>> that authors occasionally ask for by the ability to style the label 
>> based on the state of the labeled control
> 
> Can you provide some pointers to such requests?

A tiny bit of googling yields these (and more):
http://stackoverflow.com/questions/4388102/can-you-style-an-active-form-inputs-label-with-just-css
http://stackoverflow.com/questions/5978239/anyway-to-have-a-label-respond-to-focus-css
http://stackoverflow.com/questions/16859542/toggling-styles-on-label-active-focus-for-input-field-with-css-only
http://stackoverflow.com/questions/3359390/how-can-i-activate-a-css-style-for-a-label-when-hovering-over-the-associated-che
http://stackoverflow.com/questions/10408068/html-label-before-input-css-inputhoverlabel

> I proposed the /.../ combinator long ago which would actually address 
> this. The idea of that combinator was that it would let you walk 
> relationships between elements. For example, we could define a "for" 
> relationship for labels and controls, so that you could do:
> 
>   input:hover /for/ label { }
> 
> ...or some such. This would be a much more generic solution.

Right, I am also pushing for this (or some alternative syntax like a 
functional-notation pseudo-class), and it's getting (very) mild support.
That said, /for/ takes compound selectors on both sides, making it more 
generic. This is good for expressivity, but likely comes with a performance 
cost, makes the relatively common (see above) and specialised use case of 
propagating :active and :hover back to the label slightly worse, not no mention 
more verbose.

I agree the case for this would be weaker if we had /for/, but I don't think it 
goes away entirely.

>> and taking IE’s behaviour as evidence of a lack of widespread compat 
>> issues
> 
> How recent is IE's behaviour?

Since IE10.

> The problem is that it requires extra cycles every single time you are 
> trying to check whether a :hover rule matches a control. If we add this, 
> then a rule like this:
> 
>  :hover { background: blue; }
> 
> ...requires O(N*M) extra cycles, where N is the number of controls in the 
> document and M is the average number of labels per control. Worst case, 
> you have to pay this cost every frame (60 times a second). It also 
> increases the size of the browsers, which means higher memory footprints, 
> more swapping, etc.
> 
> It all adds up.
> 
> Is the cost of these extra cycles on all pages worth the benefit to the 
> pages that use it?

I am not disagreeing there is a cost, but I don't believe it is large. In most 
cases, M will be 1 or very close to.

Also, while the argument does work for :hover, I don't think the point about 
60fps is relevant for :active. You can move a cursor quickly / continuously, 
but activation cannot go that fast.

> If you limit yourself to containment rather 
> than the for="" attribute, then you can just do:
> 
>   label:hover input { ... }

If you have nesting, then sure. But using the for attribute is a perfectly good 
way to mark things up as well.

>> As selectors is a CSS topic as much as an HTML one, I brought this to 
>> the CSS working group (mailing list then telecon) for further discussion 
>> to see if its members thought this was worth pursuing or not before 
>> coming back here.
>> 
>> The group made a resolution agreeing that :hover and :active should be 
>> made to propagate bidirectionally between labels and labeled controls, 
>> as the behaviour was found useful, and the performance question not 
>> problematic.
> 
> Given that two vendors here said the performance question was problematic, 
> I question that judgement.

For Mozilla, while Boris Zbarsky did raise a concern about performance here, 
David Baron in the CSSWG said he had no issue with it.

For Apple, Ryosuke said (paraphrasing) "given that you can use :has(), it 
doesn't seem justified". But you cannot use ":has()" for selectors in CSS (see 
http://dev.w3.org/csswg/selectors/#profiles).

Microsoft already has it.

Google (via Tab Atkins) was explicitly i

Re: [whatwg] Parsing of meta refresh needs tweaking

[Simon Pieters]

On Wed, 07 Jan 2015 08:55:02 +0100, Julian Reschke   
wrote:



On 2015-01-07 08:52, Simon Pieters wrote:

 ...

I hear (a) these pages have been broken in IE for a long time, and (b)
only 23 (?) pages in your DB are found.


Right.


So why not just leave them broken?


It's a worse user experience and it's a shorter path to interop to
change IE.
...


User experience for invalid content is one aspect; sane parsing rules  
are another one. Not requiring the parameter name will make it harder to  
introduce new parameters in the future.


If you want a new parameter *in place of* URL=, you're better off using a  
different http-equiv value. If you want a new parameter in addition to  
URL=, that would still be possible if URL= is first and it uses quotes.


That said, I doubt new parameters will be introduced here, and the parsing  
is already not sane.


--
Simon Pieters
Opera Software