Re: [whatwg] Proposal: Inline pronounce element (Tab Atkins Jr.)
On Jun 5, 2014, at 22:08, Tab Atkins Jr. wrote:
> On Thu, Jun 5, 2014 at 11:29 AM, Nils Dagsson Moskopp
> wrote:
>> Brett Zamir writes:
>>
>>> On 6/5/2014 3:05 AM, whatwg-requ...@lists.whatwg.org wrote:
On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris
wrote:
> Hello,
>
> With existing assistive technology such as screen readers, and more
> recently the pervasiveness of new technologies such as Siri and Google
> Now to name two examples, I have been thinking about the
> appropriateness and potential of having a way to represent the
> pronunciation of words on a web page.
>
> There is currently no other text-level semantic that I know of for
> pronunciation, but we have elements for abbreviation and definition.
>
> As an initial suggestion:
>
> iPad
>
> (Where the `ipa` attribute is the pronunciation using the
> International Phonetic Alphabet.)
>
> What are your thoughts on this, or does something already exist that I
> am not aware of?
This is already theoretically addressed by ,
linking to a well-defined pronunciation file format. Nobody
implements that, but nobody implements anything new either, of course.
>>>
>>> I think it'd be a lot easier for sites, say along the lines of
>>> Wikipedia, to support inline markup to allow users to get a word
>>> referenced at the beginning of an article, for example, pronounced
>>> accurately.
>>
>> Is there any reason one cannot use the element for pronunciation?
>>
>> Example:
>>
>> Elfriede Jelinek (ɛlˈfʀiːdə ˈjɛlinɛk)
>>
>
> That's adequate for visually providing the pronunciation, but I think
> the original request was for a way to tell screen readers and similar
> tools how to pronounce an unfamiliar word.
True, but one could still use for its semantics, and visually use the
CSS to hide the pronunciations:
rp, rt, rtc { display: none; }
Screen readers may have supported reading text in instead of its base text
when they supported Japanese. At least some screen readers in Japan does this.
/koji
Re: [whatwg] getSelection().modify() in vertical writing modes
I'd like to note that there were very similar discussion on CSS Writing Modes
spec. Most native speakers prefers logical, while non-native tends to prefer
physical. I'd like to explain how it went for your references.
What CSS WG ended up with is to go with physical, but there's one catch you
should keep in mind. There are two kinds of direction; one you can interpret
either physical or logical, and the other you cannot. In CSS, 'margin-top' can
be interpreted in either physical or logical, while 'text-align: left' cannot
align text to visual left because then it's no longer a function to align text
within lines.
So what CSS WG defined these are:
1. For properties that can be interpreted either way, use physical (visual)
directions
2. For properties that are line-oriented, we define 'line-left' and
'line-right' as in the table in the spec[1] and use line-relative mappings[2]
In this case, you're trying to define behavior for:
modify('move', 'left/right', 'character')
So you have a choice between:
1. Make left/right as line-left/right as in the table[1], or
2. Change the meaning of 'character' to 'line'
Because there's no sense to move left/right by 'character' in vertical text
flow.
I'd suggest option 1, since it's the option CSS WG agreed with, and changing
'character' to 'line' has far larger impact than changing 'left/right' to
logical. 'character' and 'line' are two different models. For instance, 'line'
does not have bidi reordering. You can't select a single character when
text-orientation: sideways-left[3] (see the figure below the definition.)
If there were good enough use cases for physical directions, you could add:
modify('move', 'left/right', 'physical')
but I'd suggest not to change the meaning of 'character'.
[1] http://dev.w3.org/csswg/css3-writing-modes/#logical-to-physical
[2] http://dev.w3.org/csswg/css3-writing-modes/#line-mappings
[3] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation
Regards,
Koji
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Daniel Danilatos
Sent: Wednesday, June 29, 2011 2:37 PM
To: Ojan Vafai
Cc: Alexey Proskuryakov; Ryosuke Niwa; Koji Ishii; Ehsan Akhgari;
whatwg@lists.whatwg.org; Boris Zbarsky; Aryeh Gregor
Subject: Re: [whatwg] getSelection().modify() in vertical writing modes
My two cents, take it or leave it:
These specs and implementations are still quite immature and it's fine
to change their meaning slightly. So many things keep
breaking/changing anyway in the world of editing in practice anyway,
that there's not much point pretending to maintain backwards
compatibility especially for very new/immature features.
Up/Down/Left/Right should be visual directions, Forward/Back, with the
appropriate granularity, logical directions. This is kind of similar
to the whole idea of 'user intent' events - in some cases, I want to
know if the user wants to "paste", so I should get this event
regardless of whether they hit edit paste, ctrl+v, apple+v on a mac,
or with a custom key binding, etc. On the other hand, sometimes I just
want to know what key was pressed, with what modifiers, maybe I'm
implementing custom hotkeys or something, so then I want Ctrl+V as an
event. In the same vein, I want to know both what the "low level"
action was, i.e. did the user want to go visually left/right, and what
the "logical" action was, should we go forward or backward. I know
we're not necessarily talking about events, but the same applies to
modifying selections.
(Side topic: why are these capabilities on selections at all? Seems
like we're conflating two use cases. I might want to comprehend a word
boundary or a line boundary in my app logic, without touching the
selection. Seems like all this should be methods on text regions or
something like that, which could then in some scenarios be used to
modify the selection).
Dan
On Tue, Jun 28, 2011 at 8:33 AM, Ojan Vafai wrote:
> On Mon, Jun 27, 2011 at 2:39 PM, Alexey Proskuryakov wrote:
>
>> 27.06.2011, в 14:30, Ryosuke Niwa написал(а):
>>
>> FYI, I also posted this question on public-html-ig...@w3.org, and I got
>> exactly one response from Koji, who was supportive of my proposal.
>>
>> Given that, I'm inclined to say that the consensus is to modify('move',
>> 'left'/'right', 'character') should move the caret in the direction of
>> line-left and line-right and modify('move', 'left'/'right', 'line') should
>> move the caret in the block direction (left for backw
Re: [whatwg] Constraint validation feedback (various threads)
Thank you for the reply. > Anyway, do you have any concern about the behaviors of the current browsers? No, not as of now particularly. Neither I know how UAs are going to implement "require that authors not let authors enter values longer than the maxlength" behavior, sorry for the ignorance. I just worried since I saw some applications in the past that don't allow users to enter values longer than the maxlength, and some of them were unusable with CJK input methods. If you're going to change the definition to "not to allow entering values longer than the maxlength," I wish it be clearly defined with international environment in mind where text may be shorten as user types, and therefore they must allow longer values than maxlength during the undetermined state. Transition from undetermined to determined could be kicked by several criteria and it's hard to control, so my gut feeling is that "not allowing entering longer values than maxlength" tends to result poor in CJK, but I'm fine as long as it was designed such conditions in mind. Regards, Koji From: tk...@google.com [mailto:tk...@google.com] On Behalf Of TAMURA, Kent Sent: Friday, March 25, 2011 1:07 PM To: Koji Ishii Cc: wha...@whatwg.org Subject: Re: [whatwg] Constraint validation feedback (various threads) On Thu, Mar 24, 2011 at 13:37, Koji Ishii mailto:kojii...@gluesoft.co.jp>> wrote: Does that cover the case where multiple characters can be composed to single character? I'm thinking the case where undetermined text in CJK input methods tends to be longer and may be shortened once determined, but there may be more cases where text gets shorter as you type. Ishii-san, It's not related to this thread. Anyway, do you have any concern about the behaviors of the current browsers? -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Constraint validation feedback (various threads)
Does that cover the case where multiple characters can be composed to single character? I'm thinking the case where undetermined text in CJK input methods tends to be longer and may be shortened once determined, but there may be more cases where text gets shorter as you type. Regards, Koji On 2011/03/24, at 12:18, "TAMURA, Kent" wrote: > > >> Ok. It seems the best solution is to just remove the "suffering from being >> too long" state and simply require that authors not let authors enter >> values longer than the maxlength. Right? > > > I agree removing tooLong validity. > > Google Chrome 10 has the interactive validation, and is causing some > compatibility issues about maxlength. > http://www.google.com/support/forum/p/Chrome/thread?tid=4f612fe2abafc365&hl=en > > -- > TAMURA Kent > Software Engineer, Google > > >
