[Bug 10821] i18n comment 17 : setting input and textarea element direction through browser UI should set the dir attribute and trigger oninput event

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10821

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |10809

--- Comment #22 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-11-04 07:20:57 UTC ---
(In reply to comment #21)
> 1. As you can see in the comments on bug 10809, I strenuously object to that
> proposed solution (wrapping the value in bidi formatting characters when the
> user sets the direction on an input or textarea element that has the submitdir
> attribute) on the grounds that bidi formatting characters are evil in an
> abundant variety of ways. If this is how submitdir worked, I would be the first
> to recommend not to use it.

The details of the solution to bug 10809 aren't important here; the point is
that the information would be exposed to script one way or another, so the use
case described above is possible to do with that solution in place.


> 2. As I keep pointing out in comments on bug 10809, you can't get the user-set
> direction just by checking the first character of the value. If the first
> character is indeed LRE or RLE, you would then still have to scan right through
> the whole string to make sure that its balancing PDF is the last character of
> the string.

That's a discussion for that bug.


> 3. The proposed solution does not address the current lack of interoperability,
> where some browsers set the input's dir attribute, and some don't - unless you
> are also proposing adding to the specification that the user's setting the
> direction should not set the dir attribute (regardless of whether submitdir is
> on). Is this something you really want to do?

I don't understand what this is is referring to. What browsers affect the DOM?
Can you attach a test case showing the interoperability problem? Is that the
problem this bug is trying to fix? If this is a separate issue, please file a
separate bug for it.


> 4. All browsers change the effective alignment of the input when the user sets
> its direction. This is important visual feedback, and users expect it. If you
> propose to specify that the user setting the direction should not set the dir
> attribute, what justification is there for changing the effective alignment?

This doesn't seem related to this bug, which is (as far as I can tell) about
scripts being able to tell what direction the user has picked, when the user
picks it.

In any case, why would you need any justification? It's a form control, the
browser could display it with characters alternating alignment every two
seconds and it would still be conforming to the HTML spec. That's a
presentational matter. HTML is by design presentation-agnostic.


Anyway. It seems like simply making sure that the data that is submitted for
bug 10809 is also available in the DOM, and that events are fired when it
changes, would resolve this bug, right?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 4 November 2010 07:21:00 UTC