I agree with Werner.
On Thu, Dec 20, 2012 at 2:37 AM, Werner Punz <[email protected]> wrote: > > I am not sure if it really makes sense to offload attributes into separate > tags unless they are common to more than one component. > Aka styleClass and style yes, currentDayCellClass etc... definitely not it > does not make sense to introduce a tag where an attribute suffices, > otherwise we will end up with something like the Maven syntax which is a tag > soup par excellence. > > So I am not opposed to the idea (probably as Leo said, could be done > generically with a tagHandler) > > But I dont see a usecase for our WCAG extensions here, which are calendar > specific. > > > Werner > > > > Am 19.12.12 22:01, schrieb Leonardo Uribe: > >> Hi >> >> MM >> I had the idea once that one could have an extra embedded style tag >> which >> MM >> goes with each one of the extended components. So you could >> embed this tag, >> MM >> and set the style attributes there, and the main component would >> stay clean. >> >> To be more specific, the idea could be move the code from this: >> >> <t:inputCalendar id="secondOne" >> monthYearRowClass="yearMonthHeader" weekRowClass="weekHeader" >> popupButtonStyleClass="standard_bold" >> currentDayCellClass="currentDayCell" >> value="#{calendarBean.secondDate}" renderAsPopup="true" >> >> popupTodayString="#{example_messages['popup_today_string']}" >> popupDateFormat="MM/dd/yyyy" >> popupWeekString="#{example_messages['popup_week_string']}" >> helpText="MM/DD/YYYY"/> >> >> to something like this? >> >> <t:inputCalendar id="secondOne" >> value="#{calendarBean.secondDate}" renderAsPopup="true" >> popupDateFormat="MM/dd/yyyy" >> helpText="MM/DD/YYYY"> >> <t:styleAttributes >> monthYearRowClass="yearMonthHeader" >> weekRowClass="weekHeader" >> >> popupButtonStyleClass="standard_bold" >> >> currentDayCellClass="currentDayCell" >> >> popupTodayString="#{example_messages['popup_today_string']}" >> >> popupWeekString="#{example_messages['popup_week_string']}" /> >> </t:inputCalendar> >> >> Or maybe this: >> >> <t:inputCalendar id="secondOne" >> value="#{calendarBean.secondDate}" renderAsPopup="true" >> popupDateFormat="MM/dd/yyyy" >> helpText="MM/DD/YYYY"> >> <t:styleAttributes >> value="#{styleAppScopeBean.calendarPropertyMap}"/> >> </t:inputCalendar> >> >> And move the styling attribute from the markup to an application scope >> bean like >> the proposal in JSF 2.2 related to f:attributes tag?. >> >> I think with just a facelet TagHandler it is possible to do it. Maybe >> have a generic style tag and >> a special style tag for calendar component, because calendar has a lot >> of related attributes. >> >> regards, >> >> Leonardo Uribe >> >> 2012/12/19 Cagatay Civici <[email protected]>: >>> >>> Hi, >>> >>> I decided to go with a javascript bundle in PF as calendar is a special >>> component in terms or localization and internationalization. >>> >>> http://code.google.com/p/primefaces/wiki/PrimeFacesLocales >>> >>> Regards, >>> >>> Cagatay Civici >>> PrimeFaces Lead >>> Prime Teknoloji >>> www.prime.com.tr >>> >>> On 19 Ara 2012, at 22:04, Martin Marinschek <[email protected]> >>> wrote: >>> >>> Hi guys, >>> >>> >>> Wdyt? >>> >>> best regards, >>> >>> Martin >>> >>> >>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <[email protected]> >>> wrote: >>>> >>>> >>>> +1 >>>> >>>> The benefits outweigh the overcrowding of attributes, in my opinion. >>>> >>>> >>>> On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> +1 >>>>> >>>>> I think the proposal looks good, the names used in the properties are >>>>> ok, >>>>> and >>>>> there is certainty that the changes are useful. >>>>> >>>>> regards, >>>>> >>>>> Leonardo >>>>> >>>>> 2012/12/19 Werner Punz <[email protected]>: >>>>>> >>>>>> Ok just to be more precise, I have integrated the changes now locally, >>>>>> but I >>>>>> am not committing them yet, because it would mean to introduce another >>>>>> set >>>>>> of attributes to the Calendar yet. >>>>>> >>>>>> I just want the opinion whether we should do it. >>>>>> Just to give s small description, the attributes would add alt texts >>>>>> to the popup calendar and default alt texts are set anyway, the inline >>>>>> calendar does not have images hence no alt is needed and possible. >>>>>> >>>>>> The downside of this is that we add another set of attributes: >>>>>> >>>>>> popupLeftArrowAlt >>>>>> , popupRightArrowAlt >>>>>> , popupMonthArrowAlt >>>>>> , popupYearArrowAlt >>>>>> , popupCloseButtonAlt >>>>>> , calendarIconAlt >>>>>> , popupWeekOfYearTitle >>>>>> , popupWeekOfDateTitle >>>>>> >>>>>> which is a huge set of new attributes to the already attribute >>>>>> overloaded >>>>>> calendar. >>>>>> >>>>>> So what is your opinion guys, shall we add it or not. >>>>>> I favor for a +1 here, since accessability is a big plus >>>>>> and the new attributes are optional in their usage. >>>>>> >>>>>> Werner >>>>>> >>>>>> >>>>>> >>>>>> Am 19.12.12 11:23, schrieb Werner Punz: >>>>>> >>>>>>> Mhh shall we integrate this? >>>>>>> I personally think it would make sense with some name changes. >>>>>>> >>>>>>> >>>>>>> Werner >>>>>>> >>>>>>> Am 17.12.12 18:54, schrieb Jon Bionda: >>>>>>>> >>>>>>>> >>>>>>>> Sorry for what is likely a breach of protocol. This is a suggestion >>>>>>>> on >>>>>>>> how to make the Tomahawk Calendar more WCAG compliant. WCAG being a >>>>>>>> standard for gauging if browser based interfaces meet accessibility >>>>>>>> requirements primarily for disabled users. I joined the list a >>>>>>>> while >>>>>>>> ago to report an error I found and it was fixed promptly so I >>>>>>>> continued >>>>>>>> to watch the list and see that you are now preparing the next >>>>>>>> Tomahawk >>>>>>>> release, so maybe the timing is right. >>>>>>>> >>>>>>>> We used an older version of Tomahawk (1.0.6) and found the >>>>>>>> HtmlInputCalendar component failed the WCAG compliancy tests with >>>>>>>> respect to missing some ‘alt’ and ‘title’ attributes on tags >>>>>>>> generated >>>>>>>> by the calendar component. Some time ago, someone who has since >>>>>>>> left >>>>>>>> the company, made it mostly compliant by adding the following 8 >>>>>>>> properties to the HtmlInputCalendar – I didn’t do the compliancy >>>>>>>> testing >>>>>>>> but understand there are different levels of compliancy and these >>>>>>>> missing attributes make it fail at a basic level, so there may be >>>>>>>> more >>>>>>>> minor compliance issues which is why I can’t say it would be fully >>>>>>>> compliant. >>>>>>>> >>>>>>>> The properties with hopefully self-describing names are: >>>>>>>> >>>>>>>> calendarIconAlt >>>>>>>> >>>>>>>> popupLeftArrowAlt >>>>>>>> >>>>>>>> popupRightArrowAlt >>>>>>>> >>>>>>>> popupMonthArrowAlt >>>>>>>> >>>>>>>> popupYearArrowAlt >>>>>>>> >>>>>>>> popupCloseButtonAlt >>>>>>>> >>>>>>>> popupWeekOfYearTitle >>>>>>>> >>>>>>>> popupWeekOfDateTitle >>>>>>>> >>>>>>>> I’ve looked into forward porting the old changes to the Tomahawk >>>>>>>> 1.1.14 >>>>>>>> code base and have provided the code for adding the changes to the >>>>>>>> (org.apache.myfaces.custom.calendar) HtmlInputCalendar and >>>>>>>> HtmlCalendarRenderer classes. However, I am having trouble >>>>>>>> unravelling >>>>>>>> the precise changes that were made to the popcalendar.js file ( they >>>>>>>> seemed to have got a newer version of the js file and made the >>>>>>>> changes >>>>>>>> on it but I can’t figure out which version get got it from, probably >>>>>>>> obvious to you guys). >>>>>>>> >>>>>>>> A related change is also included and was made because part of WCAG >>>>>>>> is >>>>>>>> supporting screen readers. The text in alt and title attributes >>>>>>>> shouldn’t be using short forms of the week days (Sun, Mon, etc.) but >>>>>>>> rather their full names (Sunday, Monday, etc.). In the >>>>>>>> HtmlCalendarRenderer.getLocalizedLanguageScript() method, I see >>>>>>>> where >>>>>>>> they created a parallel String[] to weekDays to contain the full >>>>>>>> week >>>>>>>> day names. This is also added to the initData to be accessible in >>>>>>>> the >>>>>>>> javascript. We only use the calendar in popup mode so no changes >>>>>>>> were >>>>>>>> made to renderInline() but would expect it would also have to be >>>>>>>> modified to do a complete job. >>>>>>>> >>>>>>>> I zipped up the changes to the 2 java classes mentioned above (they >>>>>>>> only >>>>>>>> contained changed methods and have “WCAG change” comments >>>>>>>> identifying >>>>>>>> the changes), plus a sample properties file for default values and >>>>>>>> our >>>>>>>> popcalendar.js file. This last one is where my knowledge is >>>>>>>> insufficient to help much, but maybe you will find it useful to see >>>>>>>> how >>>>>>>> the new properties and full week name array are used. There may be >>>>>>>> other changes in the javascript file too as there was an issue >>>>>>>> related >>>>>>>> to focus. >>>>>>>> >>>>>>>> Thanks for your time and hope this helps. >>>>>>>> >>>>>>>> Jon Bionda >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Grant Smith - V.P. Information Technology >>>> Marathon Computer Systems, LLC. >>>> >>> >>> >>> >>> -- >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >> >> > >
