The whole point is DON'T support the plethora of browsers available -- only
the new ones that implement web standards, which is basically the law now
for all major competitors - and if your using some niche browser then I'd
hope you to expect problems with websites. Here are a couple of my
references (not for the weak of heart ;))
http://veerle.duoh.com/blog/comments/starting_with_css_and_bug_fixing_tips/
http://veerle.duoh.com/blog/comments/does_flash_irks_me/
http://alistapart.com/articles/tohell/

In the time and age we live in, we don't have a need to support "bad
browsers" or browsers that don't comply to web standards, we really don't.
The vendors don't support them so why should we, really -- and this coming
from somebody who is told that he "must support IE 6" because one whole
division of our company will not upgrade even though they can and should. I
know that it's a reality that people still write terrible web sites that try
to support old browsers when they should just tell people to upgrade, but it
shouldn't be required of a project used to test those websites. I reaffirm
that since we have a work around, we should leave it at that and put it in
the wiki somewhere for those people who must deal with poorly developed
websites, especially those that use HTML and XHTML elements incorrectly. And
that's why we have a wiki - we don't need to be sorry that our tool doesn't
work with bad websites, and we can provide workarounds for people testing
them. It just seems like a better idea than mucking up the project with
stuff that isn't standard. That's my opinion, restated.

This coupled with the fact that many testers cannot control and/or dictate
such things leaves us between an ideal that is somewhat less than
obtainable.


Testers can dictate this information and have the ability to change what's
going on and inform their developers that what they are doing is wrecking
the site. That is one of the jobs of testers. Now depending on the company,
and politics involved, there may need to be some intervention, but all
companies irregardless of size, location, or power in the world need to
realize that web standards help everybody and are built on the basis of
being accessible, which apparently is written into law these days:
http://alistapart.com/articles/politics/

Anyway, there you go, I'm a tester and a developer, but testing is my job
and if I see something that isn't web standards on our site then I question
it, write it up as a request/defect and then attend the meeting to help
people understand it, deal with it, and get it fixed. If my company were
using tables for layout, then I'd tell them that's the wrong way to go, but
as it is they only use tables for tabular data.

Nathan

On Fri, Oct 24, 2008 at 10:13 AM, andy sipe <[EMAIL PROTECTED]> wrote:

> Just a comment on the standards vs reality thing:
>
> While I understand and advocate the push to use correct and standard html,
> the reality is that it isn't very common to have 100% validated sites.   In
> fact, I cannot point to a single time where a project I worked on had every
> page 100% valid.   I'd be very surprised to find sites of any size and scope
> that meet this criteria while supporting the plethora of browsers versions
> available in the wild.
>
> This coupled with the fact that many testers cannot control and/or dictate
> such things leaves us between an ideal that is somewhat less than
> obtainable.
>
> Watir is a good tool because it does not always point back to standards as
> an out when something doesn't work.   In my opinion, if it can be rendered,
> watir should work with it.   Maybe this isn't always workable but in a lot
> of cases it works just fine.
>
> -andy
>
>
>
>
>
> On Fri, Oct 24, 2008 at 11:42 AM, Nathan Lane <[EMAIL PROTECTED]>wrote:
>
>> This is the XHTML document:
>> http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html
>> And attached are my two tests. "InvalidMarkup..." contains both the
>> results of the W3C Validator test and a testtables.html containing inner
>> tables, and "ValidMarkup..." contains both the results of the W3C Validator
>> test and a testtables.html NOT containing inner tables.
>>
>> Just for reference.
>>
>>
>> On Fri, Oct 24, 2008 at 9:18 AM, Nathan Lane <[EMAIL PROTECTED]>wrote:
>>
>>> I'm wondering whether or not this should be a defect really, because
>>> according to this standards document about tables (
>>> http://www.w3.org/TR/html401/struct/tables.html) tables probably
>>> shouldn't be contained in tables. I know that the site you're testing is
>>> probably using tables as a means of layout, which is outdated and has always
>>> been an incorrect use of tables. One alternative to trying to fix something
>>> that isn't really broken is to tell your developers that using tables for
>>> layout is invalid HTML 4/XHTML and to update it to today's web standards. I
>>> don't really think that Watir is what's broken here, rather it is the web
>>> site that is using a broken method. I may be wrong about the site your
>>> testing using tables for layout, but if it is using tables for layout, then
>>> that's invalid HTML according to W3C.
>>> Just some thoughts.
>>>
>>> Nathan
>>>
>>> On Fri, Oct 24, 2008 at 6:48 AM, Moochie <[EMAIL PROTECTED]>wrote:
>>>
>>>>
>>>> Someone posted this code and it worked really well for me.
>>>>
>>>> #Get actual row count when enbedded tables exists
>>>> def get_row_count_minus_enbedded_rows(table)
>>>>    num_rows=0
>>>>    begin
>>>>      (1..table.row_count).each do |i|
>>>>        num_rows = i
>>>>        table[i]
>>>>     end
>>>>    rescue
>>>>  end
>>>>  return num_rows
>>>> end
>>>>
>>>>
>>>>
>>>> On Oct 23, 10:08 pm, "Alan Baird" <[EMAIL PROTECTED]> wrote:
>>>> > Paul -
>>>> > This issue is WTR-26
>>>> > (http://jira.openqa.org/browse/WTR-26)<
>>>> http://jira.openqa.org/browse/WTR-26>,
>>>> > it's been around for a while.  Your solution looks like the one that
>>>> is in
>>>> > this ticket.
>>>> >
>>>> > Alan
>>>> >
>>>> > On Thu, Oct 23, 2008 at 9:10 PM, Paul Denize <
>>>> [EMAIL PROTECTED]>wrote:
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > Overloading the following seems to get past the limitations.
>>>>  Perhaps
>>>> > > someone with more DOM experience can comment if there are any
>>>> dangers
>>>> >
>>>> > > One thin I did notice is that it picks up <TH> data cells just like
>>>> > > <TD> ones
>>>> >
>>>> > > class Table
>>>> > >    def row_count
>>>> > >        assert_exists
>>>> > >        return @o.rows().length
>>>> > >    end
>>>> >
>>>> > >    def to_a
>>>> > >      assert_exists
>>>> > >      y = []
>>>> > >      table_rows = @o.rows()
>>>> > >      for row in table_rows
>>>> > >        puts row.to_a.inspect
>>>> > >        x = []
>>>> > >        for td in row.cells()
>>>> > >          x << td.innerText.strip
>>>> > >        end
>>>> > >        y << x
>>>> > >      end
>>>> > >      return y
>>>> > >    end
>>>> >
>>>> > > end- Hide quoted text -
>>>> >
>>>> > - Show quoted text -
>>>>
>>>>
>>>
>>>
>>> --
>>> Nathan Lane
>>> Home, http://www.nathandelane.com
>>> Blog, http://nathandelane.blogspot.com
>>>
>>
>>
>>
>> --
>> Nathan Lane
>> Home, http://www.nathandelane.com
>> Blog, http://nathandelane.blogspot.com
>>
>>
>>
>
> >
>


-- 
Nathan Lane
Home, http://www.nathandelane.com
Blog, http://nathandelane.blogspot.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Watir General" group.
To post to this group, send email to watir-general@googlegroups.com
Before posting, please read the following guidelines: 
http://wiki.openqa.org/display/WTR/Support
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/watir-general
-~----------~----~----~----~------~----~------~--~---

Reply via email to